jit-lock-stealth-load

jit-lock-stealth-load

[Stephen Gildea]

I would like to see the default value of jit-lock-stealth-load lowered
from 200 to 100.

With the current value of 200, I can have some foreground,
compute-intensive process running, and unbeknownst to me, Emacs is
slowing me down stealthily fontifying a large buffer because the load is
only 175%.  It is only when I have two other processes running that the
load will rise above 200% and Emacs stop interfering.  That is too
intrusive.

A value of 100 stops jit-lock-stealth from working when my CPU becomes
100% busy.  That seems like exactly the right moment for jit-lock to get
out of the way.

 < Stephen

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: jit-lock-stealth-load

[Eli Zaretskii]

On Fri, 22 Mar 2002, Stephen Gildea wrote:

> I would like to see the default value of jit-lock-stealth-load lowered
> from 200 to 100.

Sounds reasonable.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: jit-lock-stealth-load

[Richard Stallman]

I wonder if there is some way we can make jit-lock gradually
reduce its activities as the load moves above 100, turning off
when it gets to around 150 or 200.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: jit-lock-stealth-load

[Stephen Gildea]

>   I wonder if there is some way we can make jit-lock gradually
>   reduce its activities as the load moves above 100, turning off
>   when it gets to around 150 or 200.

This appeals to me, because the load reported to jit-lock is of course a
moving average, and one wants jit-lock to respond to instantaneous load.
But I would want it to gradually reduce activity much earlier, turning
off completely at 100.  The magic number is still 100%.

How about something like this:  jit-lock notes the current time, and
does a chunk of a buffer.  Then it notes the time again and adjusts
its chunk size to try to keep its compute time constant, say 0.1 second.
This keeps Emacs responsive on all speeds of CPU.  Then it checks the
load.  If we are at or above the limit, sleep for 30 seconds and check
the load again.  If we are below the limit, sleep for

 d*(a - n)/(m - a)  with a min of 0 secs and a max of 10 secs.

where m is jit-lock-stealth-load (default *still* 100)
      n is the point at which we start backing off (normally m-100)
      a is actual system load average
      d is the time it took to do the last chunk

This makes Emacs contribute just enough load to drive the system load
towards the limit, backing off as we get close.  The value of n is m-100
because Emacs can contribute at most a load of 100%.  If the actual load
is less than m-100, then Emacs cannot raise it to m even by running
continuously; above m-100, Emacs might need to back off to avoid
overshooting m.

But this would complicate the code, and I'm plenty happy with the
current, simple algorithm and jit-lock-stealth-load set to 100.

 < Stephen

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: jit-lock-stealth-load

[Richard Stallman]

I don't think jit-lock-stealth-load should (by default)
turn off completely at load 100.  It should proceed but
limit itself to 10% of the machine.  That is a good
compromise between the two goals.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: jit-lock-stealth-load

[Francesco Potorti`]

Richard Stallman <rms@gnu.org> writes:

   I wonder if there is some way we can make jit-lock gradually
   reduce its activities as the load moves above 100, turning off
   when it gets to around 150 or 200.

Turnng it off altogether is not wise.  My box currently runs
simulations that use many processes.  To keep the machine usable
(though slow) I keep those process at nice -20.  This makes thm run,
but I can use interactive programs.  My normal process load varies
between 4 and 15, depending on how many simulations I run.  I do not
want font lock stop working in this situation.

Maybe it is reasonable to slow it proportionally to the load, starting
with load = 0.5 or 0.7.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug#139792: emacs21: Press PageDown, get infinite loop

[Richard Stallman]

    Sure.. if there is somewhere I can find instructions on how to do that?

Browse savannah.gnu.org and look for the `emacs' project.
There should be instructions there for how to build from the CVS sources.
If they are not clear, please complain here so we can clarify them.

Re: Bug#139792: emacs21: Press PageDown, get infinite loop

[Nick]

Thank you.  The instructions are fine, but I failed to find them when looking 
under http://www.gnu.org and under http://cvs.gnu.org (latter was just a 
guess, this was before the emails from you and Eli Zaretskii).  Perhaps I 
missed a link.  The place I looked at most was at and under 
http://www.gnu.org/software/software.html#HowToGetSoftware.

>     Sure.. if there is somewhere I can find instructions on how to do that?
> 
> Browse savannah.gnu.org and look for the `emacs' project.
> There should be instructions there for how to build from the CVS sources.
> If they are not clear, please complain here so we can clarify them.
> 

Re: Emacs crash in X

[Satyaki Das]

Richard Stallman <rms@gnu.org> writes:

> I use Sawfish; does it have any analogous feature?
> If so, can someone tell me how to do this with Sawfish?

I don't have sawfish installed on my current machine. I used
to have it on a previous machine that has since died. There is
a program called sawfish-ui (which is a GUI config utility).
That has an option to choose workspaces instead of viewports.

> You can also debug this yourself.  Run Emacs under GDB then
> evaluate (x-synchronize t), then make it fail.

If I evaluate (x-synchronize t) then emacs doesn't die any
more.

>                                                 That way you
> will get a useful backtrace.  Please read etc/DEBUG for more
> suggestions for how to debug this.

So I read etc/DEBUG and followed the recommendations there.
First I simplified the test program to:

(progn
  (setq focus-follows-mouse nil)
  (x-focus-frame (window-frame (get-buffer-window "*scratch*" t))))

Then I set a break point on Fx_focus_frame. Then I started
emacs (with -q --no-site-file) from inside gdb and did the
following:

1. C-x 5 2 to create new frame.

2. Move new frame to a different workspace and switch back to
   the original workspace.

3. Load the file containing the test program in the frame in
   the current workspace with C-x C-f ~/pp.el
   The file pp.el contains:
     (progn
       (setq focus-follows-mouse nil)
       (x-focus-frame (window-frame (get-buffer-window "*scratch*" t))))

4. Go to the end of the file and evaluate the expression with:
       M-> C-x C-e
   [When evaluating the expression the setup needed is that
    there should be two frames one showing *scratch* and the
    other showing pp.el and they are be in separate
    workspaces.]

5. The break point in Fx_focus_frame is hit. Now I use next to
   step through, evaluating:
     call XSync (f->output_data.x->display_info->display, 0)
   whenever I am about to execute XSetInputFocus statement.
   Here I tried three different things:
     1. call XSync ... before and after the XSetInputFocus
        statement as etc/DEBUG says to do. This doesn't make
        emacs to die.
     2. call XSync ... after the XSetInputFocus statement.
        Emacs doesn't die here either.
     3. call Xsync before the XSetInputFocus. Emacs goes into
        x_error_quitter.

6. The backtrace for case 3 above is as follows:

   #0  x_error_quitter (display=0xbffd13d4, error=0x402b8b28) at xterm.c:12415
   #1  0x080b7fc2 in x_error_handler (display=0x84e17f0, error=0xbffd12e4)
       at xterm.c:12433
   #2  0x40211831 in _XError () from /usr/X11R6/lib/libX11.so.6
   #3  0x4020fdcf in _XReply () from /usr/X11R6/lib/libX11.so.6
   #4  0x401fcf1c in XInternAtom () from /usr/X11R6/lib/libX11.so.6
   #5  0x4053edd1 in _XimExtension ()
      from /usr/X11R6/lib/X11/locale/common/ximcp.so.2
   #6  0x4022b845 in XFilterEvent () from /usr/X11R6/lib/libX11.so.6
   #7  0x080b52c1 in XTread_socket (sd=0, bufp=0xbffd2a94, numchars=4096, 
       expected=1) at xterm.c:10210
   #8  0x080dd770 in read_avail_input (expected=1) at keyboard.c:6462
   #9  0x080dd926 in input_available_signal (signo=29) at keyboard.c:6615
   #10 <signal handler called>
   #11 0x42028cc1 in kill () from /lib/i686/libc.so.6
   #12 0x080dd952 in reinvoke_input_signal () at keyboard.c:6644
   #13 0x080c3a05 in Fx_focus_frame (frame=1213197936) at xfns.c:4720
   #14 0x0812eb52 in Feval (form=135835064) at eval.c:2097
   #15 0x0812c661 in Fprogn (args=0) at eval.c:425
   #16 0x0812eca4 in Feval (form=1210509112) at eval.c:2044
   #17 0x0812f506 in Ffuncall (nargs=2, args=0xbffff014) at eval.c:2742
   #18 0x0815707c in Fbyte_code (bytestr=407579124, vector=1, 
       maxdepth=-1073745904) at bytecode.c:709
   #19 0x0812f7f7 in funcall_lambda (fun=1210349712, nargs=1, 
       arg_vector=0xbffff144) at eval.c:2929
   #20 0x0812f3df in Ffuncall (nargs=2, args=0xbffff140) at eval.c:2799
   #21 0x0815707c in Fbyte_code (bytestr=407579100, vector=1, 
       maxdepth=-1073745600) at bytecode.c:709
   #22 0x0812f7f7 in funcall_lambda (fun=1210350268, nargs=1, 
       arg_vector=0xbffff284) at eval.c:2929
   #23 0x0812f3df in Ffuncall (nargs=2, args=0xbffff280) at eval.c:2799
   #24 0x0812b201 in Fcall_interactively (function=405469220, 
       record_flag=405469220, keys=1210835384) at callint.c:819
   #25 0x080e16a2 in Fcommand_execute (cmd=405554668, record_flag=405469220, 
       keys=405469220, special=405469220) at keyboard.c:9536
   #26 0x080d6fb2 in command_loop_1 () at keyboard.c:1690
   #27 0x0812d9ee in internal_condition_case (bfun=0x80d6c88 <command_loop_1>, 
       handlers=405565828, hfun=0x80d6884 <cmd_error>) at eval.c:1353
   #28 0x080d6b6e in command_loop_2 () at keyboard.c:1274
   #29 0x0812d591 in internal_catch (tag=0, func=0x80d6b50 <command_loop_2>, 
       arg=405469220) at eval.c:1114
   #30 0x080d6b24 in command_loop () at keyboard.c:1253
   #31 0x080d6663 in recursive_edit_1 () at keyboard.c:969
   #32 0x080d6770 in Frecursive_edit () at keyboard.c:1025
   #33 0x080d50cb in main (argc=3, argv=0xbffffa44) at emacs.c:1659
   #34 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

So it seems that adding a XSync after the call to
XSetInputFocus avoids the problem. I have verified that by
recompiling after making this change.

Satyaki

Re: Emacs crash in X

[Richard Stallman]

The backtrace doesn't *prove* anything, but all the evidence strongly
suggests that the error comes from the XSetInputFocus function.

I suspect it is an error to specify a window on a different workspace.
I suspect the bug is the failure to call XSync so as to detect the
error before x_uncatch_errors.

It looks like you're testing the latest CVS sources now.  I just
installed a fix in xterm.c and alloc.c that I hope will fix this.
Does it?

Re: Emacs crash in X

[Satyaki Das]

Richard Stallman <rms@gnu.org> writes:

> It looks like you're testing the latest CVS sources now.  I just
> installed a fix in xterm.c and alloc.c that I hope will fix this.
> Does it?

I just did a cvs up and I am glad to report that the problem
is no longer there :-).

Thanks,
Satyaki

Re: [bob@rattlesnake.com: `whitespace-describe' function missing]

[Rajesh Vaidheeswarran]

Sure.. I'll look into it and fix it, if broken.. I have no idea
why the defun would've gotten lost..

rv


In a previous message, Richard Stallman writes:

> Can you please take care of this issue?
> 
> ------- Start of forwarded message -------
> Date: Fri, 11 Apr 2003 13:21:17 -0400 (EDT)
> From: "Robert J. Chassell" <bob@rattlesnake.com>
> To: emacs-devel@gnu.org
> Subject: `whitespace-describe' function missing
> Reply-To: bob@rattlesnake.com
> Sender: emacs-devel-bounces+rms=gnu.org@gnu.org
> 
>     Today's GNU Emacs CVS snapshot, Fri, 2003 Apr 11  12:37 UTC
> 
> In `lisp/whitespace.el', the `whitespace-cleanup' function says
> 
>     Use \\[describe-function] whitespace-describe to read a summary of the
>     whitespace problems."
> 
> but the `whitespace-describe' function does not exist!
> 
> The `whitespace problems' are described in the `whitespace-buffer'
> function and in the `lisp/whitespace.el' commentary.
> 
> - -- 
>     Robert J. Chassell                         Rattlesnake Enterprises
>     http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
>     http://www.teak.cc                             bob@rattlesnake.com
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> ------- End of forwarded message -------
> 

Re: RMAIL, MIME-related bug

[Peter S Galbraith]

Richard Stallman <rms@gnu.org> wrote:

>     > They should be in lisp/mail/, not in lisp/gnus/.  In other words, they
>     > should be in common Emacs infrastructure, documented in
>     > lispref/*.texi, and all the Emacs mail packages should use them.
> 
> If they are a general facility, they should definitely be moved;
> the main repository for them should be the Emacs repository.
> 
>       Currently, some
>     fancier capabilities of MH-E are only availble if the user has also
>     installed a separate recent version of gnus since the Emacs version is
>     too old.
> 
> If you distribute MH-E outside of Emacs, you can distribute whatever
> you like with it.

We distribure a few contrib files that are not part of MH-E proper, but
we let users fetch gnus for themselves.  (On Debian systems, the mh-e
package simply recommends the gnus package.)

Peter

Re: decode_eol and inconsistent EOL

[Richard Stallman]

    That kind of heuristic is bound to trip some people, I think.  It's
    difficult to set a threshold that will suit everyone.  It's also
    difficult for users to set such a threshold, if we give them an
    option.

A threshold may be the wrong way to decide, but it could be that a
mixture CRLFs with some extra CRs should be accepted as DOS-style.

Re: decode_eol and inconsistent EOL

[Stephen Gildea]

>   A threshold may be the wrong way to decide, but it could be that a
>   mixture CRLFs with some extra CRs should be accepted as DOS-style.

More generally, we could have a mapping of sets of line-endings
observed to what eol encoding to use.  I would then enter in
this table (("\r\n" "\r\r\n") . 'dos).

Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

> Date: Fri, 26 Apr 2002 11:38:37 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
> it could be that a mixture CRLFs with some extra CRs should be
> accepted as DOS-style.

Are we sure that Mac users (where a single CR is the EOL character)
won't object this?

Re: decode_eol and inconsistent EOL

[Stefan Monnier]

> > Date: Fri, 26 Apr 2002 11:38:37 -0600 (MDT)
> > From: Richard Stallman <rms@gnu.org>
> > 
> > it could be that a mixture CRLFs with some extra CRs should be
> > accepted as DOS-style.
> 
> Are we sure that Mac users (where a single CR is the EOL character)
> won't object this?

Mac users don't have LFs at all so there shouldn't be any ambiguity.
If there is no LFs and some CRs -> Mac.
If all the LFs are preceded with CR -> Dos.
Else -> Unix.


	Stefan

Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>
> Date: Fri, 26 Apr 2002 16:39:54 -0400
> > 
> > Are we sure that Mac users (where a single CR is the EOL character)
> > won't object this?
> 
> Mac users don't have LFs at all

Really?  Why not?  AFAIK, the LF on a Mac is like a CR on Unix--it's a
control character that can appear in a file.

Re: decode_eol and inconsistent EOL

[Stefan Monnier]

> > From: "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>
> > Date: Fri, 26 Apr 2002 16:39:54 -0400
> > > 
> > > Are we sure that Mac users (where a single CR is the EOL character)
> > > won't object this?
> > 
> > Mac users don't have LFs at all
> 
> Really?  Why not?  AFAIK, the LF on a Mac is like a CR on Unix--it's a
> control character that can appear in a file.

Look at the code: if there's an LF anywhere, the mac decoding fails
and reverts to unix style eol.

This is a current limitation of Emacs because it cannot distinguish
(inside an Emacs buffer) between an "LF character" and an
"eol character", so an LF char from a Mac-eol file cannot be decoded
to an LF (since it would be encoded back as a CR).  We could of course
decode them to something completely different (like CR which will
currently never be output by the decoding of a Mac-eol file), but then
people would find it rather surprising.


	Stefan

Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

On Sun, 28 Apr 2002, Stefan Monnier wrote:

> Look at the code: if there's an LF anywhere, the mac decoding fails
> and reverts to unix style eol.

Sure.  But what you suggest will cause it to revert to DOS style 
instead; that's a change.  All I'm saying is that we should consider
the Mac users when we make this change, in case it will somehow screw 
them.

> This is a current limitation of Emacs because it cannot distinguish
> (inside an Emacs buffer) between an "LF character" and an
> "eol character", so an LF char from a Mac-eol file cannot be decoded
> to an LF (since it would be encoded back as a CR).

Similar problems exist on Windows, although not with Emacs.

Re: decode_eol and inconsistent EOL

[Stefan Monnier]

> 
> On Sun, 28 Apr 2002, Stefan Monnier wrote:
> 
> > Look at the code: if there's an LF anywhere, the mac decoding fails
> > and reverts to unix style eol.
> 
> Sure.  But what you suggest will cause it to revert to DOS style 
> instead;

No, please check again.  All I do is that we switch from dos->unix a bit
less often.  Mac is completely unaffected.


	Stefan

Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Mon, 29 Apr 2002 09:02:52 -0400
> 
> No, please check again.

I did, believe me.  (Btw, I think there's at least one more place in
coding.c that needs a similar change, should we install this.)

> All I do is that we switch from dos->unix a bit less often.  Mac is
> completely unaffected.

I believe there's a misunderstanding: you are talking about Mac EOL
type, while I was thinking about Mac _users_.

A file on a Mac can be auto-detected as a DOS-style file.  Since
auto-detection only examines the first 3 lines, it could err,
especially with files whose EOLs are inconsistent.  When
auto-detection yields DOS EOL style, your patch _will_ affect
user-level behavior.  If and when that happens, Windows users might
not mind, since DOS EOLs are their ``native'' style.  But I wonder
whether Mac users will see this the same way.

More generally, it is not clear to me why is it better to remove one
CR before each LF, but leave the other in the buffer.  Either way, the
display is ugly, and it's clear that something is wrong.  However,
while with the current code the two CRs will clearly show the problem,
with the change you suggest users might become confused (``why did
Emacs display the CRs even though the mode line says "(DOS)"?'').

I understand that sometimes the effect of this change is desirable;
Stephen's case is one such situation.  However, for the
above-mentioned reasons, I think a decision whether this is
appropriate is a burden best left to the user, especially since
Mule-related changes tend to cause unintended consequences.  That is
why a user option like dos-eols-okay-even-if-we-find-stray-CRs sounds
like a better way to solve this.  Perhaps we should even have a more
general always-honor-detected-eol-style option, which would disable
the current logic of reverting to unconverted EOLs if inconsistency is
found.

Re: decode_eol and inconsistent EOL

[Richard Stallman]

    A file on a Mac can be auto-detected as a DOS-style file.

Just as a file on Windows or GNU can be auto-detected as a DOS-style
file.

      Since
    auto-detection only examines the first 3 lines, it could err,
    especially with files whose EOLs are inconsistent.

Whatever we do, there will be a possibility of error.

      When
    auto-detection yields DOS EOL style, your patch _will_ affect
    user-level behavior.

Of course it will affect user-level behavior.
That is the purpose.

So far you have not made an argument against this change.

    More generally, it is not clear to me why is it better to remove one
    CR before each LF, but leave the other in the buffer.  Either way, the
    display is ugly, and it's clear that something is wrong.

It is much less ugly if the file is treated as DOS-style.

      However,
    while with the current code the two CRs will clearly show the problem,
    with the change you suggest users might become confused (``why did
    Emacs display the CRs even though the mode line says "(DOS)"?'').

I don't think it is any more confusing than anything else.

I think this change should be installed.

Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

On Mon, 29 Apr 2002, Richard Stallman wrote:

> So far you have not made an argument against this change.

I wasn't arguing against the change.  I was brainstorming its possible 
consequences.  Bitter experience had taught me that Mule-related changes 
frequently have unexpected side effects, so I thought it would be useful 
to look at this from several aspects before the decision is made.

Re: decode_eol and inconsistent EOL

[Richard Stallman]

    > it could be that a mixture CRLFs with some extra CRs should be
    > accepted as DOS-style.

    Are we sure that Mac users (where a single CR is the EOL character)
    won't object this?

Is there a reason why a Mac file would have LFs after some of the CRs?

Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

On Sun, 28 Apr 2002, Richard Stallman wrote:

>     Are we sure that Mac users (where a single CR is the EOL character)
>     won't object this?
> 
> Is there a reason why a Mac file would have LFs after some of the CRs?

No more than a Windows file would have a stray CR, I guess.

Basically, we are talking about two possible classes of cases here:

  - binary files

  - text files produced by broken programs

In the first case, what Emacs does now is the Right Thing.

In the second case, which was Stephen's problem, a broken program can 
produce stray LFs on a Mac as much as it can produce a stray CR on 
Windows.

But I don't use the Mac, so perhaps such problems don't exist there.  
Andrew, could you please advise?  Thanks.

Re: decode_eol and inconsistent EOL

[Andrew Choi]

> On Sun, 28 Apr 2002, Richard Stallman wrote:
> 
> >     Are we sure that Mac users (where a single CR is the EOL
> >     character) won't object this?
> > 
> > Is there a reason why a Mac file would have LFs after some of the CRs?
> 
> No more than a Windows file would have a stray CR, I guess.
>
> Basically, we are talking about two possible classes of cases here:
> 
>   - binary files
> 
>   - text files produced by broken programs
> 
> In the first case, what Emacs does now is the Right Thing.
> 
> In the second case, which was Stephen's problem, a broken program can 
> produce stray LFs on a Mac as much as it can produce a stray CR on 
> Windows.

I agree.  Not that I have actually seen any program on the Mac that
does this.  But since we are talking about pathological cases,
anything may happen.

Of course Mac OS X uses CR's as EOL's, so the problem is the same
there as for other Unix systems.

Re: decode_eol and inconsistent EOL

[Stefan Monnier]

> Of course Mac OS X uses CR's as EOL's, so the problem is the same
> there as for other Unix systems.

You mean "Mac OS X uses LFs", right ?


	Stefan

Re: decode_eol and inconsistent EOL

[Andrew Choi]

> > Of course Mac OS X uses CR's as EOL's, so the problem is the same
> > there as for other Unix systems.
> 
> You mean "Mac OS X uses LFs", right ?

You're right.  It should be LF's (not CR's).

Re: decode_eol and inconsistent EOL

[Richard Stallman]

    I agree.  Not that I have actually seen any program on the Mac that
    does this.  But since we are talking about pathological cases,
    anything may happen.

Anything may happen, so any policy we choose could sometimes give
wrong results.  The issue here is about which policy tends to give
correct results.  Therefore, to argue that a policy *could* be wrong
is neither here nor there.  That is true for all the alternatives.
Will it really happen in practice.

Re: decode_eol and inconsistent EOL

[Richard Stallman]

    Basically, we are talking about two possible classes of cases here:

      - binary files

      - text files produced by broken programs

    In the first case, what Emacs does now is the Right Thing.

Would the other behavior really be much less right,
in the case of a binary file?

Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

> Date: Mon, 29 Apr 2002 12:40:07 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
>     Basically, we are talking about two possible classes of cases here:
> 
>       - binary files
> 
>       - text files produced by broken programs
> 
>     In the first case, what Emacs does now is the Right Thing.
> 
> Would the other behavior really be much less right,
> in the case of a binary file?

The other behavior inhibits all EOL conversions, so it shows the
contents of a binary file's more accurately.  That's not an
overwhelming advantage, but I don't see any significant advantages in
the suggested change, either.  In the absence of significant
advantages, I think the defaults should not change.

Re: decode_eol and inconsistent EOL

[Stefan Monnier]

> The other behavior inhibits all EOL conversions, so it shows the
> contents of a binary file's more accurately.  That's not an
> overwhelming advantage, but I don't see any significant advantages in
> the suggested change, either.  In the absence of significant
> advantages, I think the defaults should not change.

The advantage is that it allows the inclusion of lone CR chars
in dos-style files and it makes the code simpler.

Binary file whose first "three lines" look like dos-style files
are much less frequent in my experience than broken text files
(probably because CRLF are frequently converted to/from LF, so
it's quite common to end up with an extra CR or a missing CR.
For technical reasons Emacs can't handle a lone LF in a dos-style
file, but that's not the case for lone CRs).
I've wasted too much of my time on this detail anyway.


	Stefan

Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

On Mon, 29 Apr 2002, Stefan Monnier wrote:

> The advantage is that it allows the inclusion of lone CR chars
> in dos-style files and it makes the code simpler.

Yes.

Anyway, I don't feel strongly about either the current or the suggested 
*modus operandi*.

Re: decode_eol and inconsistent EOL

[Richard Stallman]

      In the absence of significant
    advantages, I think the defaults should not change.

We have already seen a significant advantage, in the case
that brought up this decision.  That is enough reason for the change
if there is no concrete reason on the other side.

Integrate Tramp

[Kai Großjohann]

Finally, I'd like to integrate Tramp into Emacs.  How is the
procedure?  Do I just commit something or do I post it here for
inspection?

Without further instructions, I would commit lisp/net/tramp.el and
lisp/net/tramp-vc.el for the code and man/tramp.texi for the
documentation.

There is also tramp_ja.texi for a Japanese version of the manual and
tramp-util.el which contains just one short function, tramp-compile,
as a remote analog of `compile'.  These should not be committed, I
think.

At the moment, tramp.el contains a version number (the $Id$
keyword).  I gather that you're not happy with having version numbers
in Lisp files.  But I think it would be useful to continue to support
a version of Tramp which is not bundled with Emacs.  Then people can
try out new Tramp features without having to fetch the most recent
Emacs version from CVS.  Advice?

kai
-- 
People mountain, people sea, today no see, tomorrow see.  (from Chinese)

Re: Integrate Tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Finally, I'd like to integrate Tramp into Emacs.

'bout time...

-miles
-- 
Run away!  Run away!

Re: Integrate Tramp

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> Finally, I'd like to integrate Tramp into Emacs.
>
> 'bout time...

I'm sorry.

kai
-- 
People mountain, people sea, today no see, tomorrow see.  (from Chinese)

Re: Integrate Tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > 'bout time...
> 
> I'm sorry.

Er, kidding, kidding.

I'm very glad tramp will be in emacs since I've been seeing people
enthuse about it, and have wanted to check it out for quite a while, but
never got around to doing so.  Now it's gonna be trivial.

[In fact I was recently thinking about sending you mail asking about
precisely this issue...]

Cheers,

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Integrate Tramp

[Eli Zaretskii]

On Sun, 16 Jun 2002 Kai.Grossjohann@CS.Uni-Dortmund.DE wrote:

> Without further instructions, I would commit lisp/net/tramp.el and
> lisp/net/tramp-vc.el for the code and man/tramp.texi for the
> documentation.

Don't forget to update info/dir to add a menu entry there for the Tramp 
manual.

> At the moment, tramp.el contains a version number (the $Id$
> keyword).  I gather that you're not happy with having version numbers
> in Lisp files.  But I think it would be useful to continue to support
> a version of Tramp which is not bundled with Emacs.  Then people can
> try out new Tramp features without having to fetch the most recent
> Emacs version from CVS.  Advice?

How about making the version string be something that CVS will not 
recognize?  That means you will have to update the version manually, but 
perhaps that's not such a big deal?

Re: Integrate Tramp

[Kai Großjohann]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Sun, 16 Jun 2002 Kai.Grossjohann@CS.Uni-Dortmund.DE wrote:
>
>> Without further instructions, I would commit lisp/net/tramp.el and
>> lisp/net/tramp-vc.el for the code and man/tramp.texi for the
>> documentation.
>
> Don't forget to update info/dir to add a menu entry there for the Tramp 
> manual.

Will do.

>> At the moment, tramp.el contains a version number (the $Id$
>> keyword).  I gather that you're not happy with having version numbers
>> in Lisp files.  But I think it would be useful to continue to support
>> a version of Tramp which is not bundled with Emacs.  Then people can
>> try out new Tramp features without having to fetch the most recent
>> Emacs version from CVS.  Advice?
>
> How about making the version string be something that CVS will not 
> recognize?  That means you will have to update the version manually, but 
> perhaps that's not such a big deal?

Yes, that's a good idea.  So I now created version 2.0.0, which I
will commit soonish.

kai
-- 
People mountain, people sea, today no see, tomorrow see.  (from Chinese)

Re: Integrate Tramp

[Richard Stallman]

    Finally, I'd like to integrate Tramp into Emacs.  How is the
    procedure?  Do I just commit something or do I post it here for
    inspection?

I'd like to see the diffs you propose to install in the existing
files.  One question is, how will the user control whether to use
Tramp or Ange-ftp?

    Without further instructions, I would commit lisp/net/tramp.el and
    lisp/net/tramp-vc.el for the code and man/tramp.texi for the
    documentation.

Ok.

    At the moment, tramp.el contains a version number (the $Id$
    keyword).  I gather that you're not happy with having version numbers
    in Lisp files.  But I think it would be useful to continue to support
    a version of Tramp which is not bundled with Emacs.  Then people can
    try out new Tramp features without having to fetch the most recent
    Emacs version from CVS.  Advice?

If nobody but you has to edit the version number then I do not object
to it.

Re: Integrate Tramp

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     Finally, I'd like to integrate Tramp into Emacs.  How is the
>     procedure?  Do I just commit something or do I post it here for
>     inspection?
>
> I'd like to see the diffs you propose to install in the existing
> files. 

No problem.  I only changed two files.

I added an entry in info/dir:

/----
| Index: dir
| ===================================================================
| RCS file: /cvsroot/emacs/emacs/info/dir,v
| retrieving revision 1.23
| retrieving revision 1.24
| diff -u -u -r1.23 -r1.24
| --- dir	16 Mar 2002 19:32:15 -0000	1.23
| +++ dir	17 Jun 2002 11:46:10 -0000	1.24
| @@ -55,6 +55,9 @@
|  * Forms: (forms).	Emacs package for editing data bases
|  			  by filling in forms.
|  * RefTeX: (reftex).	Emacs support for LaTeX cross-references and citations.
| +* Tramp: (tramp).	Transparent Remote (file) Access, Multiple Protocol.
| +                          Edit remote files via a remote shell (rsh,
| +                          ssh, telnet).
|  * Widget: (widget).     The "widget" package used by the Emacs Customization
|                            facility.
|  * WoMan: (woman).       Browse UN*X Manual Pages "Wo (without) Man".
\----


And I added entries in man/Makefile.in:

/----
| Index: Makefile.in
| ===================================================================
| RCS file: /cvsroot/emacs/emacs/man/Makefile.in,v
| retrieving revision 1.43
| retrieving revision 1.44
| diff -u -u -r1.43 -r1.44
| --- Makefile.in	4 Jan 2002 10:47:13 -0000	1.43
| +++ Makefile.in	17 Jun 2002 11:46:09 -0000	1.44
| @@ -39,13 +39,13 @@
|  		../info/efaq ../info/ada-mode ../info/autotype ../info/calc \
|  		../info/idlwave ../info/eudc ../info/ebrowse ../info/pcl-cvs \
|  		../info/woman ../info/emacs-mime ../info/eshell \
| -		../info/speedbar
| +		../info/speedbar ../info/tramp
|  DVI_TARGETS = 	emacs.dvi calc.dvi cc-mode.dvi cl.dvi dired-x.dvi \
|  		 ediff.dvi forms.dvi gnus.dvi message.dvi mh-e.dvi \
|  		 reftex.dvi sc.dvi vip.dvi viper.dvi widget.dvi faq.dvi \
|  		 ada-mode.dvi autotype.dvi idlwave.dvi eudc.dvi ebrowse.dvi \
|  		 pcl-cvs.dvi woman.dvi emacs-mime.dvi eshell.dvi \
| -		 speedbar.dvi
| +		 speedbar.dvi tramp.dvi
|  INFOSOURCES = info.texi
|  
|  # The following rule does not work with all versions of `make'.
| @@ -266,6 +266,11 @@
|  	cd $(srcdir); $(MAKEINFO) emacs-mime.texi
|  emacs-mime.dvi: emacs-mime.texi
|  	$(ENVADD) $(TEXI2DVI) ${srcdir}/emacs-mime.texi
| +
| +../info/tramp: tramp.texi
| +	cd $(srcdir); $(MAKEINFO) tramp.texi
| +tramp.dvi: tramp.texi
| +	$(ENVADD) $(TEXI2DVI) ${srcdir}/tramp.texi
|  
|  mostlyclean:
|  	rm -f *.log *.cp *.fn *.ky *.pg *.vr core *.tp *.core gnustmp.*
\----


> One question is, how will the user control whether to use Tramp or
> Ange-ftp?

Simply via the filename.  /[user@host]/path/to/file (including the
square brackets) is a Tramp filename, whereas
/user@host:/path/to/file is an Ange-FTP filename.

>     At the moment, tramp.el contains a version number (the $Id$
>     keyword).  I gather that you're not happy with having version numbers
>     in Lisp files.  But I think it would be useful to continue to support
>     a version of Tramp which is not bundled with Emacs.  Then people can
>     try out new Tramp features without having to fetch the most recent
>     Emacs version from CVS.  Advice?
>
> If nobody but you has to edit the version number then I do not object
> to it.

Okay.

kai
-- 
People mountain, people sea, today no see, tomorrow see.  (from Chinese)

Re: Integrate Tramp

[Eli Zaretskii]

> From: Kai.Grossjohann@CS.Uni-Dortmund.DE
> Date: Mon, 17 Jun 2002 18:44:19 +0200
> 
> No problem.  I only changed two files.

Kai, did you add an entry to NEWS?  If not, I think you should.

Re: Integrate Tramp

[Kai Großjohann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Kai, did you add an entry to NEWS?  If not, I think you should.

Thanks for the reminder, I totally forgot.  Done.

kai
-- 
People mountain, people sea, today no see, tomorrow see.  (from Chinese)

Re: Integrate Tramp

[Kim F. Storm]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> 
> > Kai, did you add an entry to NEWS?  If not, I think you should.
> 
> Thanks for the reminder, I totally forgot.  Done.

You should also add the tramp(*) info file to the 
install and uninstall targets in Makefile.in.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Integrate Tramp

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> You should also add the tramp(*) info file to the 
> install and uninstall targets in Makefile.in.

Thank you.  Done.

kai
-- 
People mountain, people sea, today no see, tomorrow see.  (from Chinese)

Re: Integrate Tramp

[Eli Zaretskii]

On Mon, 17 Jun 2002 Kai.Grossjohann@CS.Uni-Dortmund.DE wrote:

> > One question is, how will the user control whether to use Tramp or
> > Ange-ftp?
> 
> Simply via the filename.  /[user@host]/path/to/file (including the
> square brackets) is a Tramp filename, whereas
> /user@host:/path/to/file is an Ange-FTP filename.

The /[user@host] notation should probably be mentioned in the Emacs 
manual (where remote file names are discussed), with a reference to the 
Tramp manual.

Re: Integrate Tramp

[Kai Großjohann]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> The /[user@host] notation should probably be mentioned in the Emacs 
> manual (where remote file names are discussed), with a reference to the 
> Tramp manual.

Done.  (Node "Remote Files".)

kai
-- 
People mountain, people sea, today no see, tomorrow see.  (from Chinese)

Re: Integrate Tramp

[Richard Stallman]

    Simply via the filename.  /[user@host]/path/to/file (including the
    square brackets) is a Tramp filename, whereas
    /user@host:/path/to/file is an Ange-FTP filename.

I see now.  When I saw this before I did not realize that the
brackets were meant literally.

The way you did it looks safe, but is this really the right interface
to use?  Or should we add a way to make /user@host:/path/to/file file
names optionally invoke Tramp?

Perhaps they should use Tramp when USER is specified, and use ange-ftp
for anonymous access.  Would that be the useful combination?

Re: Integrate Tramp

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> The way you did it looks safe, but is this really the right interface
> to use?  Or should we add a way to make /user@host:/path/to/file file
> names optionally invoke Tramp?
> 
> Perhaps they should use Tramp when USER is specified, and use ange-ftp
> for anonymous access.  Would that be the useful combination?

I think not, since tramp can be used without a user too (for instance,
with ssh).  Also, it's not uncommon to use ange-ftp for non-anonymous
users.

I suspect that whether you wanth to use tramp or ftp depends on both the
machine and the user; I would be happy with a variable that let me
specify mappings from these to the method to use (plus a default for
otherwise unspecified machines, of course).

Actually, I'm surprised that trampt itself seems to have no method of
defaulting things (such as the connection method) for particular
machines (and users, though it would be be able to have default user for
particular machines too, if no user is specified); perhaps the same
mechanism could be used for both things.  For instance, there could be
a magic tramp connection-method called `ftp', which would cause the
tramp code to just hand over to ange-ftp.

-miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Integrate Tramp

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Richard Stallman <rms@gnu.org> writes:
> > The way you did it looks safe, but is this really the right interface
> > to use?  Or should we add a way to make /user@host:/path/to/file file
> > names optionally invoke Tramp?
> > 
> > Perhaps they should use Tramp when USER is specified, and use ange-ftp
> > for anonymous access.  Would that be the useful combination?
> 
> I think not, since tramp can be used without a user too (for instance,
> with ssh).  Also, it's not uncommon to use ange-ftp for non-anonymous
> users.
> 
> I suspect that whether you wanth to use tramp or ftp depends on both the
> machine and the user; I would be happy with a variable that let me
> specify mappings from these to the method to use (plus a default for
> otherwise unspecified machines, of course).
> 

I agree.

> Actually, I'm surprised that trampt itself seems to have no method of
> defaulting things (such as the connection method) for particular
> machines (and users, though it would be be able to have default user for
> particular machines too, if no user is specified); perhaps the same
> mechanism could be used for both things.

The default for unknown hosts could be 'detect, meaning it should
detect the best method to use to connect to that host -- and save
that info somewhere (e.g. .emacs or .tramp).

>   For instance, there could be
> a magic tramp connection-method called `ftp', which would cause the
> tramp code to just hand over to ange-ftp.

Nice idea.

If the default connection method for unknown hosts was 'ftp,
ange-ftp would work as today; it could also be the fall-back
for 'detect if none of the tramp methods work.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Integrate Tramp

[Richard Stallman]

    If the default connection method for unknown hosts was 'ftp,
    ange-ftp would work as today; it could also be the fall-back
    for 'detect if none of the tramp methods work.

That sounds good.  I have one question, though: how long does it take
to test the various tramp methods?  I could imagine that if they involve
trying to open network connections it could take many seconds or even minutes
to test them.  Can you tell us a definitive answer?

Re: Integrate Tramp

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     If the default connection method for unknown hosts was 'ftp,
>     ange-ftp would work as today; it could also be the fall-back
>     for 'detect if none of the tramp methods work.
>
> That sounds good.  I have one question, though: how long does it take
> to test the various tramp methods?  I could imagine that if they involve
> trying to open network connections it could take many seconds or even minutes
> to test them.  Can you tell us a definitive answer?

There are a lot of things which could be auto-detected.  For example,
Tramp could auto-detect whether mimencode or uuencode should be used
in an "inline" method.  This kind of thing is fairly quick to test
and, what with all the other auto-detecting that is already going on,
it wouldn't make much of a difference, efficiency-wise.

But I'm not so happy about auto-detecting which program should be used
to connect to the remote host.  Suppose that Tramp tries "ssh", then
"ssh -2", then "ssh -1", then "rlogin", then "telnet" and possibly
also the Kerberized login programs.  First of all, waiting for a
timeout from all these programs could take a long time.  Secondly, it
might result in the user getting asked strange questions.  (Suppose
Tramp tries to log me in to the GNU machines with Kerberos, but I've
never used Kerberos.  Then I'd get asked Kerberos questions which I
don't know how to answer.)¹

Also note that (length tramp-methods) => 30.  Maybe a handful of
these methods are not necessary anymore.  But the lion's share of
them were added by me because they fulfilled a real need.  Maybe this
gives you some idea about the task to do auto-detection.

Another remark:

It would be great if Tramp could auto-detect everything.  But I've
been working on Tramp for a while and so I know that it will take me
a long time to implement all of this.  (If I can do it at all.)  So
my suggestion is to keep "more auto-detection" in mind as a long-term
goal, to work towards this goal in a step-by-step fashion, and to
design the current interface (filename syntax) for Tramp in such a
way that the auto-detection is not necessary for Tramp to work.

I think that Tramp is useful even if it does not do more
auto-detection.

Note: I want to add caching to Tramp so that auto-detection only
needs to happen once for a given user/host combination.

kai

¹ I hope that Kerberos really asks questions.  I don't know, I've
  never used Kerberos.  But this was just intended as an example --
  feel free to replace this example with another one.
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Robert J. Chassell]

   There are a lot of things which could be auto-detected.  ... the
   lion's share of them were added by me because they fulfilled a real
   need.

I can see that full auto-detection will fill a real need, but
nonetheless, partial detection might help in a large portion of
situations.  It looks to me that you could ignore the external methods
for the moment and focus on only four major connection methods and two
inline transfer methods:

    ftp
    telnet
    ssh protocol 1
    ssh protocol 2

    mimencode
    uuencode and uudecode

with the priority being

    sm
    smx
    su

and if those fail, then ask, with a default priority of
ftp and then telnet, tm and tu.

I agree that the info should be cached in a humanly readable and
humanly editable configure file.

And I agree that it is even more important to enable tramp to connect
to sites that provide ssh and uuencode, such as the sites I go to .... :)

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Integrate Tramp

[Kai Großjohann]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> I can see that full auto-detection will fill a real need, but
> nonetheless, partial detection might help in a large portion of
> situations.

I agree with that.

> It looks to me that you could ignore the external methods for the
> moment and focus on only four major connection methods and two
> inline transfer methods:
>
>     ftp
>     telnet
>     ssh protocol 1
>     ssh protocol 2

Just for the heck of it, let me give an argument against this
auto-detection:  Most likely, people using ssh are interested in the
security it provides.  So suppose a user often uses Tramp to connect
to other machines, where ssh is used.  Now the user connects to a new
machine which does not provide ssh but telnet.  So Tramp will use
telnet on that machine.  And then the user will use an insecure
transport channel, without really being very much aware of it.  This
is dangerous.

All of you guys have been arguing for auto-detection, so I felt a
counter-weight was needed.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Robert J. Chassell]

   ... So Tramp will use
   telnet on that machine.  And then the user will use an insecure
   transport channel, without really being very much aware of it.  This
   is dangerous.

I have always been assuming that tramp would tell me, quite vividly,
what method I am using.  (The autodetection might put the method into
the file name or something like that.)  I am now and want in the
future to be very conscious of which kind of transport channel I am
using.

Hmmm.... if auto-detection takes place behind my back -- that is to
say, I simply find-file somewhere and don't see that the transport
channel is telnet, then I am stuck.  I have to assum the worst.

I hate to say it, but I think that auto-detection should add the name
of the method to the filename, so I see and notice it when the
filename changes during the connection process.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Integrate Tramp

[Kai Großjohann]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> I have always been assuming that tramp would tell me, quite vividly,
> what method I am using.  (The autodetection might put the method into
> the file name or something like that.)  I am now and want in the
> future to be very conscious of which kind of transport channel I am
> using.

Currently, Tramp indeed puts the method in the filename.  (It breaks
completion, though.  That's why I spend the few extra characters to
type the method name, too...  Maybe I should really find the bug why
it breaks completion.)

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Richard Stallman]

    > I have always been assuming that tramp would tell me, quite vividly,
    > what method I am using.  (The autodetection might put the method into
    > the file name or something like that.)  I am now and want in the
    > future to be very conscious of which kind of transport channel I am
    > using.

    Currently, Tramp indeed puts the method in the filename.

That seems like a useful feature, but I wonder where you 
can do it without its being an anomalous thing to change the file name.
Which operation does this?

I suppose if expand-file-name does it there will be no anomaly, since
it normally returns a file name that is different from the one you
gave it.  Is that what you did?

Re: Integrate Tramp

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     Currently, Tramp indeed puts the method in the filename.
>
> That seems like a useful feature, but I wonder where you 
> can do it without its being an anomalous thing to change the file name.
> Which operation does this?
>
> I suppose if expand-file-name does it there will be no anomaly, since
> it normally returns a file name that is different from the one you
> gave it.  Is that what you did?

No, all operations changed the filename.  Thank you for helping me
with this!  I will try to change the filename in expand-file-name,
I guess that might help with the breakage.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Richard Stallman]

      So suppose a user often uses Tramp to connect
    to other machines, where ssh is used.  Now the user connects to a new
    machine which does not provide ssh but telnet.

There could be various options to control autodetection; one could say
whether to try telnet or not, and another could say whether to try ftp
or not.  People who want security could turn off autodetection's use
of telnet and ftp.  Then they would have to specify those methods
explicitly when they want to use them.

Perhaps the defaults should not include telnet or ftp, and you should
have to request them explicitly when you want them.

Re: Integrate Tramp

[Richard Stallman]

    But I'm not so happy about auto-detecting which program should be used
    to connect to the remote host.  Suppose that Tramp tries "ssh", then
    "ssh -2", then "ssh -1", then "rlogin", then "telnet" and possibly
    also the Kerberized login programs.  First of all, waiting for a
    timeout from all these programs could take a long time.

I had a feeling that might be the case.  Autodetection is only a
feasible solution to the problem of choosing the program if it can be
done reasonably fast.

Bob suggests autodetection might be ok for a certain usual set of
programs.  What do you think?

Re: Integrate Tramp

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> Bob suggests autodetection might be ok for a certain usual set of
> programs.  What do you think?

I assume the quickest way to find out if the remote host supports ssh
is to just try a connection on the ssh port on that machine.

I just tried to connect to port 22 on my desktop machine (which is
not reachable because it's behind a firewall).  I used
open-network-stream.  It's been waiting for a couple of minutes
already, and no timeout in sight.¹

Presumably, ssh would be the first thing to try (over telnet and ftp).

I stand by my previous opinion: do not try to auto-detect whether ssh
or telnet or Kerberos login or SSL-Telnet or ftp or whatnot should be
used.  Let the user specify this.

But do try to autodetect the other parameters, once the network
application has been set.  For example, autodetect whether base64
encoding or uuencoding should be used.  Possibly it's also possible
to figure out whether and out-of-band method should be used.

kai

¹ Is this experiment unfair due to our specific firewall
  configuration?  I'm not a networking expert.
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Stefan Monnier]

> I stand by my previous opinion: do not try to auto-detect whether ssh
> or telnet or Kerberos login or SSL-Telnet or ftp or whatnot should be
> used.  Let the user specify this.

Complete agreement.

> But do try to autodetect the other parameters, once the network
> application has been set.  For example, autodetect whether base64
> encoding or uuencoding should be used.  Possibly it's also possible
> to figure out whether and out-of-band method should be used.

Agreed as well.  You might even just go ahead and assume mimencode
is available and if it fails revert to perl and if that also fails
default to uu(en|de)code (so you only do the detection if it is needed).

> ¹ Is this experiment unfair due to our specific firewall
>   configuration?  I'm not a networking expert.

I don't think so.


	Stefan

Re: Integrate Tramp

[Richard Stallman]

    I suspect that whether you wanth to use tramp or ftp depends on both the
    machine and the user; I would be happy with a variable that let me
    specify mappings from these to the method to use (plus a default for
    otherwise unspecified machines, of course).

I think we need to implement this now, before the next release,
because having two alternative syntaxes for remote file names is not a
coherent interface.  It is usable for wizards, but not clean and nice.

If we can arrange to use the same remote file name syntax
that people are used to, it will also mean less for users to learn.

Re: Integrate Tramp

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     I suspect that whether you wanth to use tramp or ftp depends on both the
>     machine and the user; I would be happy with a variable that let me
>     specify mappings from these to the method to use (plus a default for
>     otherwise unspecified machines, of course).
>
> I think we need to implement this now, before the next release,
> because having two alternative syntaxes for remote file names is not a
> coherent interface.  It is usable for wizards, but not clean and nice.

I have now written some code which hooks into Ange-FTP.  For some
filenames, the Tramp functions instead of the Ange-FTP functions are
called.  (This is intended as a proof of concept, some changes would
be needed before it's included with Tramp.  It's not nice style to
just redefine the ange-ftp function...)

(require 'ange-ftp)

(defvar tramp-override-ange-ftp-alist
  '(("grossjoh@schulz" "sm"))
  "*Use Tramp for these Ange-FTP filenames.
Elements are (TARGET METHOD) where TARGET is a string of the form
\"USER@HOST\" and METHOD is a Tramp method name (also a string).")

(defun ange-ftp-hook-function (operation &rest args)
  (let* ((fn (get operation 'ange-ftp))
	 (parsed-name (ange-ftp-ftp-name (car args)))
	 (host (and parsed-name (nth 0 parsed-name)))
	 (user (and parsed-name (nth 1 parsed-name)))
	 (path (and parsed-name (nth 2 parsed-name)))
	 (method (and user host
		      (assoc (format "%s@%s" user host)
			     tramp-override-ange-ftp-alist))))
    (cond (method
	   ;; Invoke Tramp instead of Ange-FTP.
	   (apply 'tramp-file-name-handler
		  operation
		  (cons (tramp-make-tramp-file-name
			 nil (cadr method) user host path)
			(cdr args))))
	  (fn
	   (save-match-data (apply fn args)))
	  (t
	   (ange-ftp-run-real-handler operation args)))))

With the example value for tramp-override-ange-ftp-alist, all
filenames starting with "/grossjoh@schulz:" will be handled by Tramp
(using the "sm" method).

However, internally, Tramp still uses the old filenames.  This means
that hitting C-x C-f in a buffer visiting a file via Tramp will still
show "/[sm/grossjoh@schulz]" (plus some suffix) instead of
"/grossjoh@schulz:" (plus some suffix).

The other alternative would be to change Tramp to use a filename
format that's similar to the format used by Ange-FTP and to call
Ange-FTP for some user/host combinations if the method is not
specified.  This would entail removing ange-ftp from
file-name-handler-alist, I guess.  It would also mean that all Tramp
filenames should use the Ange-FTP `style'.

What do you think?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> The other alternative would be to change Tramp to use a filename
> format that's similar to the format used by Ange-FTP and to call
> Ange-FTP for some user/host combinations if the method is not
> specified.  This would entail removing ange-ftp from
> file-name-handler-alist, I guess.  It would also mean that all Tramp
> filenames should use the Ange-FTP `style'.

I think you should do this.

My impression is that the main reason you chose the [...] syntax for
tramp is to avoid conflicts with ange-ftp; it seems cleaner and more
user-friendly to just use the same syntax for both, especially since
ange-ftp's syntax is basically a subset of tramp's, and now you have
the freedom to integrate them.

I think most people would agree that the ange-ftp-style syntax is a bit
nicer anyway (and familiar to more people), especially when most of the
details are defaulted based on the machine name or whatever.

[You could support the old tramp syntax by translating it to the
ange-ftp-style syntax]

BTW, it seems like a somewhat arbitrary fact that the package doing
remote-access is called `tramp', so how about giving the variable used
to specify remote access methods a more generic name like
`remote-file-...' or something?

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Integrate Tramp

[Richard Stallman]

    However, internally, Tramp still uses the old filenames.  This means
    that hitting C-x C-f in a buffer visiting a file via Tramp will still
    show "/[sm/grossjoh@schulz]" (plus some suffix) instead of
    "/grossjoh@schulz:" (plus some suffix).

That will tend to confuse users.

    The other alternative would be to change Tramp to use a filename
    format that's similar to the format used by Ange-FTP and to call
    Ange-FTP for some user/host combinations if the method is not
    specified.  This would entail removing ange-ftp from
    file-name-handler-alist, I guess.  It would also mean that all Tramp
    filenames should use the Ange-FTP `style'.

That seems like the clean approach.  Removing ange-ftp from direct
presence in the file-name-handler-alist is ok, since the feature will
still *work* properly using the new mechanism.

    Tramp knows the following kinds of filenames (square brackets are
    literal characters):

    /[host]file
    /[user@host]file
    /[method/user@host]file
    /[multi/hop1:user1@host1/hop2:user2@host2]file

(Note that I am not sure whether the strings `hop1' and `hop2' that
appear in the last example are literal or metasyntactic variables.)

I suggest these syntaxes:

    /host:file
    /user@host:file
    /user@host@method:file
    /user1@host1:user2@host2:file

If there is some sort of "hop" information that needs to be given,
the last could look like

    /user1@host1@hop1:user2@host2@hop2:file

This seems both simpler and more natural than either your current
syntax or your current proposal.  `[multi]' seems unnecessary, since
you can determine how many colons there are.  The
file-name-handler-alist can specify "^/\\([^/:]*[^/:.]:\\)+" to match
the whole prefix.

    * We designate a special method "ftp" which, when specified, invokes
      Ange-FTP.

That is a good idea.

    * Tramp is augmented with an alist of user/host pairs and default
      methods.  This alist can be used to tell Tramp to use any method,
      including "ftp", for a specific user/host combination.

    * Specifying the method in the filename overrides this alist.

Those seem like good ideas too.  Perhaps the alist should contain
regexps to match against the user and the host.

In addition, there should be a separate customizable user option that
specifies the ultimate choice of method, for when the user/host pair
is not mentioned in the alist.

Re: Integrate Tramp

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|> I suggest these syntaxes:
|> 
|>     /host:file
|>     /user@host:file
|>     /user@host@method:file
|>     /user1@host1:user2@host2:file

IMHO it would be nice to have a syntax where we can specify host and
method without a user.  Using your proposed syntax would create an
ambiguity.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Integrate Tramp

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     Tramp knows the following kinds of filenames (square brackets are
>     literal characters):
>
>     /[host]file
>     /[user@host]file
>     /[method/user@host]file
>     /[multi/hop1:user1@host1/hop2:user2@host2]file
>
> (Note that I am not sure whether the strings `hop1' and `hop2' that
> appear in the last example are literal or metasyntactic variables.)

They are metasyntactic variables.  Sorry for not making this clear.
Choices are ssh, telnet, rsh, su, sudo.  For each hop, you specify
which command should be used to log into that computer.

> I suggest these syntaxes:
>
>     /host:file
>     /user@host:file
>     /user@host@method:file
>     /user1@host1:user2@host2:file
>
> If there is some sort of "hop" information that needs to be given,
> the last could look like
>
>     /user1@host1@hop1:user2@host2@hop2:file
>
> This seems both simpler and more natural than either your current
> syntax or your current proposal.  `[multi]' seems unnecessary, since
> you can determine how many colons there are.  The
> file-name-handler-alist can specify "^/\\([^/:]*[^/:.]:\\)+" to match
> the whole prefix.

This could almost work, except that there are two multi methods.  (One
uses uuencode and the other uses base64 encoding to transfer the
files.)

In the old Tramp, you say /[multi]... for base64 and /[multiu]... for
uuencode.

Hm.

>     * We designate a special method "ftp" which, when specified, invokes
>       Ange-FTP.
>
> That is a good idea.

OK.

The following part:

>     * Tramp is augmented with an alist of user/host pairs and default
>       methods.  This alist can be used to tell Tramp to use any method,
>       including "ftp", for a specific user/host combination.
>
>     * Specifying the method in the filename overrides this alist.
>
> Those seem like good ideas too.  Perhaps the alist should contain
> regexps to match against the user and the host.
>
> In addition, there should be a separate customizable user option that
> specifies the ultimate choice of method, for when the user/host pair
> is not mentioned in the alist.

... is already implemented.  The new code is not in the Emacs CVS,
only in the Tramp CVS (on Savannah).  (I'll copy the changes soon.)
The current implementation still uses the bracket-style filenames,
but I want to change that as well, including the forward-to-Ange-FTP
feature that we were talking about.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Stefan Monnier]

> >     * Tramp is augmented with an alist of user/host pairs and default
> >       methods.  This alist can be used to tell Tramp to use any method,
> >       including "ftp", for a specific user/host combination.

How about a rewrite list, so you can also use it for
bookmark-like purposes:

	'(("user1@host1" "user1#met1@host1")
          ("host2" "user3#met3@host3|user2#met2@host2")
	  ("shorthand1" "user4#met4@host4")
	  ...)


-- Stefan

Re: Integrate Tramp

[Richard Stallman]

    This could almost work, except that there are two multi methods.  (One
    uses uuencode and the other uses base64 encoding to transfer the
    files.)

Can't that be made part of the HOP specification?
Perhaps part of the first HOP specification?
As Bob says, it is an annoying complication to have more than
one multi method.  This is true regardless of the syntax used.

Re: Integrate Tramp

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> I think we need to implement this now, before the next release,
> because having two alternative syntaxes for remote file names is not a
> coherent interface.  It is usable for wizards, but not clean and nice.
>
> If we can arrange to use the same remote file name syntax
> that people are used to, it will also mean less for users to learn.

Tramp knows the following kinds of filenames (square brackets are
literal characters):

/[host]file
/[user@host]file
/[method/user@host]file
/[multi/hop1:user1@host1/hop2:user2@host2]file

The last variant I call multi-hop method.  It can contain an
arbitrary number of hops.  A hop looks like "hop:user@host".

Ange-FTP directly supports the first two:

/host:file
/user@host:file

For the others, this syntax needs to be extended.  Hm.  Let's see.
The characters "@" and ":" should not be used to separate the
method.  But maybe the method could be in square brackets.  So the
third line becomes this:

/[method]user@host:file

That seems to be simple and easy enough.  Hm.  And for the multi-hop
methods, the hops could be separated by comma and the "hop" part
could be separated by "#", so we arrive at this format:

/[multi]hop1#user1@host1,hop2#user2@host2:file

This appears to be a fairly natural filename format which people
might like.

Now comes the question: in which cases should Tramp invoke Ange-FTP?
My ideas are:

* We designate a special method "ftp" which, when specified, invokes
  Ange-FTP.

* Tramp is augmented with an alist of user/host pairs and default
  methods.  This alist can be used to tell Tramp to use any method,
  including "ftp", for a specific user/host combination.

* Specifying the method in the filename overrides this alist.

What do you think?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Stefan Monnier]

> /[multi]hop1#user1@host1,hop2#user2@host2:file

I'd prefer /[multi]/[method1]user1@host1/[method2]user2@host2:file.
Adding more special characters is not a good idea, in my opinion.
But as I said, I'd rather see some kind of URL-like syntax.

> What do you think?

That we should probably try to synchronize with the URL package which
also provides something similar.


	Stefan

Re: Integrate Tramp

[Robert J. Chassell]

   ... And for the multi-hop methods, the hops could be separated by
   comma and the "hop" part could be separated by "#", ...

This is pretty good, except that I would like a visually stronger
connection between the two hops.  How about a `pipe' symbol, | ?
The `pipe' symbol provides the added useful connotation that you are 
tunneling through one system to get to another.

Here are two multi-hop connections that I want to make:

    /[multi]smx#bob@fencepost.gnu.org|su#bob@titan.berkshire.net:/home/bob/www

    /[multi]smx-2#bob@24.161.120.95|smx-2#bob@192.168.0.4:/home/bob/

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Integrate Tramp

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    ... And for the multi-hop methods, the hops could be separated by
>    comma and the "hop" part could be separated by "#", ...
> 
> This is pretty good, except that I would like a visually stronger
> connection between the two hops.  How about a `pipe' symbol, | ?
> The `pipe' symbol provides the added useful connotation that you are 
> tunneling through one system to get to another.
> 
> Here are two multi-hop connections that I want to make:
> 
>     /[multi]smx#bob@fencepost.gnu.org|su#bob@titan.berkshire.net:/home/bob/www
> 
>     /[multi]smx-2#bob@24.161.120.95|smx-2#bob@192.168.0.4:/home/bob/

This looks nice, but I think it could be simplified even further
if the presence of `|' implicitly specifies the multi-hop method:

     /[smx]bob@fencepost.gnu.org|[su]bob@titan.berkshire.net:/home/bob/www

     /[smx-2]bob@24.161.120.95|[smx-2]bob@192.168.0.4:/home/bob/


If not already possible, I think it would be really nice if the
"remote-method-alist" allows the specification of abbreviations,
e.g. so that

     /titan:/...

is equivalent to

     /[smx]bob@fencepost.gnu.org|[su]bob@titan.berkshire.net:/...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Integrate Tramp

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> This looks nice, but I think it could be simplified even further
> if the presence of `|' implicitly specifies the multi-hop method:

agree

> nice if the "remote-method-alist" allows the specification of abbreviations:
>      /titan:/...
> is equivalent to
>      /[smx]bob@fencepost.gnu.org|[su]bob@titan.berkshire.net:/...

agree

Tramp seems to offer a lot of nice functionality, but it's hard to
believe people have got along so far without any way of abbreviating
those complicated pathnames!

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Integrate Tramp

[Robert J. Chassell]

   ... I think it could be simplified even further if the presence of
   `|' implicitly specifies the multi-hop method:

Good idea!  I like it.  As you say, this leads to:

        /[smx]bob@fencepost.gnu.org|[su]bob@titan.berkshire.net:/home/bob/www

        /[smx-2]bob@24.161.120.95|[smx-2]bob@192.168.0.4:/home/bob/

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Integrate Tramp

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> If not already possible, I think it would be really nice if the
> "remote-method-alist" allows the specification of abbreviations,

Why not just use (setenv "X" "/some/complicated/file/name/here")?
Then you can type C-x C-f $X/foo RET.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > If not already possible, I think it would be really nice if the
> > "remote-method-alist" allows the specification of abbreviations,
> 
> Why not just use (setenv "X" "/some/complicated/file/name/here")?
> Then you can type C-x C-f $X/foo RET.

That's how I generally do `personal' abbreviations.

But in the case of a remove path, I'd like to be able to still use a
consistent naming scheme for remote addresses -- even ones with hair
paths -- and have them reflected in the filenames tramp treats as
canonical.

So if tramp requires `/foo|some@hairy|miles@gnu.org/spec' to reach my
directory at gnu.org, It would be nice to be able to just say `/gnu.org:/'
-- and also have it show up that way after completion, in buffer lists,
etc.

I think that remote paths are _often_ hairy, and so deserve some
special treatment to make them more manageable.

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: Integrate Tramp

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I think that remote paths are _often_ hairy, and so deserve some
> special treatment to make them more manageable.

Does the variable directory-abbrev-alist help here?  I read the
documentation, but I'm not sure if it helps.

I agree that it would be nice to have this feature.  I did not regard
it as important so I didn't work on it.  (I still get bug reports
about Tramp being unable to connect in some situation, which means
I've got to start hunting for some bug.)

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> This looks nice, but I think it could be simplified even further
> if the presence of `|' implicitly specifies the multi-hop method:

There are at least two multi-hop methods, multi and multiu.  multi
uses base64 encoding (using mimencode) to transfer the files, and
multiu uses uuencode.

I therefore suggest to keep the method prefix for multi-hop methods,
at least at first, until more auto-detection has been added to Tramp.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> There are at least two multi-hop methods, multi and multiu.  multi
> uses base64 encoding (using mimencode) to transfer the files, and
> multiu uses uuencode.
> 
> I therefore suggest to keep the method prefix for multi-hop methods,
> at least at first, until more auto-detection has been added to Tramp.

That's fine -- but it should be optional to specify the multi-method, and
if not specified, it use some user-specifiable default.  The plethora
of methods provided by tramp is good, but I think most people will only
want to use a few in their environment, and can default quite a bit.
[In any case, the syntax chosen should definitely make it possible to
leave out the multi-method, to allow for the future.]

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.

Re: Integrate Tramp

[Kai Großjohann]

Kai.Grossjohann@cs.uni-dortmund.de (Kai Großjohann) writes:

> * Tramp is augmented with an alist of user/host pairs and default
>   methods.  This alist can be used to tell Tramp to use any method,
>   including "ftp", for a specific user/host combination.

I have now done this (but not implemented the "ftp" method yet) as a
preparation for further work.  This feature will be useful anyway.

I will wait a bit before checking this in to the Emacs CVS.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Robert J. Chassell]

There are two multi-hop methods:

   * `multi' -- base64 encoding with `mimencode'

   * `multiu' -- use commands `uuencode' and `uudecode'

I am confused:  how do I make a multi-hop that requires both?
In particular, I would like to make a two hop connection in which the
first hop uses `mimencode' and the second hop uses `uuencode' and
`uudecode'

When I travel, I cannot connect directly to my ISP's machine from a
random IP address.  That is where I keep copies of files that will be
needed during the trip, just in case.

However, I can connect to fencepost.gnu.org which works with `smx' and
then connect to my ISP's machine which eventually should work with
`su':


    /[multi]smx#bob@fencepost.gnu.org|su#bob@titan.berkshire.net:/home/bob/

Are you suggesting that I cannot use the methods I use for single hop
connections but should use these different methods?  Like this:

    /[multi]ssh#bob@fencepost.gnu.org|[multiu]ssh#bob@titan.berkshire.net:/home/bob/

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Integrate Tramp

[Kai Großjohann]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> There are two multi-hop methods:
>
>    * `multi' -- base64 encoding with `mimencode'
>
>    * `multiu' -- use commands `uuencode' and `uudecode'
>
> I am confused:  how do I make a multi-hop that requires both?
> In particular, I would like to make a two hop connection in which the
> first hop uses `mimencode' and the second hop uses `uuencode' and
> `uudecode'

It not possible nor necessary to use a method that uses both.  Tramp
use a sequence of commands to get a shell on the remote host (on the
final host).  There, Tramp says "mimencode -b FILE".  The result of
this appears in the Emacs buffer that Tramp uses for the connection.
Tramp then gets the characters from that buffer, runs them through
base64 decoding internally, and puts the result in the buffer.

If you hop via A and then B to C, Tramp does NOT transfer the file
contents from C to B and then from B to A and from there to your local
machine.  Instead, the file contents go "directly" from C to your
local machine.

The only commands that are run on the intermediary hops are the
commands to log in to the next hop.  Once on the target machine, the
intermediary hops are invisible.

Does this explain the issue a little bit?  (Of course, the manual
needs to be improved to make it clear.  Please keep your doc bug
reports coming.)

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Robert J. Chassell]

   > I am confused:  how do I make a multi-hop that requires both?
   > In particular, I would like to make a two hop connection in which the
   > first hop uses `mimencode' and the second hop uses `uuencode' and
   > `uudecode'

   It not possible nor necessary to use a method that uses both.  ...
   If you hop via A and then B to C, ...the file contents go
   "directly" from C to your local machine.

Thank you!  Now I understand.

From this I infer that this means that you can *not* use a method like
`smx' or `su' in a multi-hop connection.  Instead, you must use only a
`plain' method, such as `ssh' or `telnet'.  The `multi'/`multiu'
distinction tells the most remote machine what to use.  Am I right?

In other words, my example should look like this:

    /[multiu]ssh#bob@fencepost.gnu.org|ssh#bob@titan.berkshire.net:/home/bob/


If so, I am a little bit bothered, since it would seem easier to me

  * to provide only one kind of `multi' tag, 

  * which would be optional, since a `multi' tag is no longer needed,

  * to tell users that they need only provide `plain' methods on the
    intermediary hops,

  * but let users provide methods like `smx' or `tu' if they wish,
    since they may simply be copying the types used for single hop
    connections.  (The `mimencode' or `uuencode' commands can be
    ignored for intermediary hops.)
    
  * and tell users that they *must* specify a `mimencode' or
    `uuencode' command for the most remote machine (unless the
    connection can automatically default or be auto-dectected).


Based on this suggestion, my file name would look like the following,
with the `smx' being read only for the SSH part and the `su' telling
Emacs that this is a uuencoding style connection:

    /smx#bob@fencepost.gnu.org|su#bob@titan.berkshire.net:/home/bob/

And I could also, equally well, write the file name like this, which
would be more `proper':

    /ssh#bob@fencepost.gnu.org|su#bob@titan.berkshire.net:/home/bob/

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Integrate Tramp

[Kai Großjohann]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Thank you!  Now I understand.
>
> From this I infer that this means that you can *not* use a method like
> `smx' or `su' in a multi-hop connection.  Instead, you must use only a
> `plain' method, such as `ssh' or `telnet'.  The `multi'/`multiu'
> distinction tells the most remote machine what to use.  Am I right?

Actually, the list of "hop methods" is in the variable
tramp-multi-connection-function-alist.  The list is also given in the
node "(tramp)Multi-hop Methods" in the info file.

> In other words, my example should look like this:
>
>     /[multiu]ssh#bob@fencepost.gnu.org|ssh#bob@titan.berkshire.net:/home/bob/

This looks correct.

> If so, I am a little bit bothered, since it would seem easier to me
>
>   * to provide only one kind of `multi' tag, 

Indeed, this would be good.  This goes well together with the
auto-detection of base64 encoding versus uuencode encoding that I've
put on my todo list.

>   * which would be optional, since a `multi' tag is no longer needed,

Yes, it wouldn't be so difficult to change Tramp so that it looks for
"|" to figure out if it's a single-hop or multi-hop filename.

>   * to tell users that they need only provide `plain' methods on the
>     intermediary hops,

I've tried to do that in the above mentioned info node.

>   * but let users provide methods like `smx' or `tu' if they wish,
>     since they may simply be copying the types used for single hop
>     connections.  (The `mimencode' or `uuencode' commands can be
>     ignored for intermediary hops.)

The "hop methods" are treated quite differently from the normal
methods, as you can see when you look at the description of the
variable tramp-multi-connection-function-alist.

(Why isn't that variable named something like
tramp-multi-method-alist?  Argh.  Sorry.)

>   * and tell users that they *must* specify a `mimencode' or
>     `uuencode' command for the most remote machine (unless the
>     connection can automatically default or be auto-dectected).

How about a different approach: The user can choose whether multi or
multiu is the default multi method.  Then, when using a "|" filename
without specifying a method, Tramp always uses the default multi
method.

> Based on this suggestion, my file name would look like the following,
> with the `smx' being read only for the SSH part and the `su' telling
> Emacs that this is a uuencoding style connection:
>
>     /smx#bob@fencepost.gnu.org|su#bob@titan.berkshire.net:/home/bob/
>
> And I could also, equally well, write the file name like this, which
> would be more `proper':
>
>     /ssh#bob@fencepost.gnu.org|su#bob@titan.berkshire.net:/home/bob/

I don't think that this approach makes sense because the information
in tramp-methods (which lists methods like smx and su) and the
information in tramp-multi-connection-function-alist is so dissimilar.

Maybe I should have used very different names for the hop methods,
such as m1 through m5...

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Robert J. Chassell]

   The "hop methods" are treated quite differently from the normal
   methods, as you can see when you look at the description of the
   variable tramp-multi-connection-function-alist.

Perhaps you can figure out how to treat them differently internally,
but to make them look similar to a plain user.

As a user, I cannot see why connecting to fencepost and titan
separately should require different methods than connecting to
fencepost and titan together.

From the IP address I am using right now, I can connect to each
individually (or will be able to when the bugs are fixed); but from
other IP addresses, I can connect directly to fencepost but then will
have to make a hop to get to titan.  In both cases, I expect to use
the same method to get to fencepost.  I think it really odd that I, a
user, should have to remove the mimencode info from the one connection
and include it in the other.  Emacs itself should be able to say;
`oh, I don't need this extra info that the user provided me; I will
throw it away'.

How about filtering "hop methods" so that internally, in the
appropriate context, `smx' becomes `ssh' ?

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Integrate Tramp

[Ehud Karni]

On Tue, 18 Jun 2002 20:23:47 -0600 (MDT), Richard Stallman <rms@gnu.org> wrote:
> 
> Perhaps they should use Tramp when USER is specified, and use ange-ftp
> for anonymous access.  Would that be the useful combination?

I object. I use the form /user@host:/ with ange-ftp at least 5 times
a day on our local network.

Ehud.


-- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.simonwiesel.co.il          Better  Safe  Than  Sorry

Re: Integrate Tramp

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Simply via the filename.  /[user@host]/path/to/file (including the
>     square brackets) is a Tramp filename, whereas
>     /user@host:/path/to/file is an Ange-FTP filename.
> 
> I see now.  When I saw this before I did not realize that the
> brackets were meant literally.
> 

Actually, the full tramp format seems to be

        /[method/user@host]/path/to/file

I think using / to separate the method is a really bad idea, as it
makes it non-trivial to parse or split a filename.

If we adapt the idea of using the same notation as ange-ftp, i.e.
        /user@host:/path/to/file
you could add the method as
        /[method]user@host:/
if you really need to specify the method (using a list of host,method
mapping and auto-detection would be much better).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Integrate Tramp

[Stefan Monnier]

> Richard Stallman <rms@gnu.org> writes:
> 
> >     Simply via the filename.  /[user@host]/path/to/file (including the
> >     square brackets) is a Tramp filename, whereas
> >     /user@host:/path/to/file is an Ange-FTP filename.
> > 
> > I see now.  When I saw this before I did not realize that the
> > brackets were meant literally.
> > 
> 
> Actually, the full tramp format seems to be
> 
>         /[method/user@host]/path/to/file

It's more than complex that because of the `multi' method which allows
you to access files via a sequence of "access methods" (e.g. ssh to host1
then ssh to host2 then su).

> I think using / to separate the method is a really bad idea, as it
> makes it non-trivial to parse or split a filename.

file-name-directory and others are your friends.

> If we adapt the idea of using the same notation as ange-ftp, i.e.
>         /user@host:/path/to/file

Tramp started with such an idea, but given all the various details
that might be embedded in a Tramp filename, it turned out to be
a problem IIRC.

And I think if we want to standardize on a common syntax, we should
go for something more like URLs.


	Stefan

Re: Integrate Tramp

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > 
> > Actually, the full tramp format seems to be
> > 
> >         /[method/user@host]/path/to/file
> 
> It's more than complex that because of the `multi' method which allows
> you to access files via a sequence of "access methods" (e.g. ssh to host1
> then ssh to host2 then su).
> 
> > I think using / to separate the method is a really bad idea, as it
> > makes it non-trivial to parse or split a filename.
> 
> file-name-directory and others are your friends.

I'm probably biased, but with ido, I read file names one
character at a time, and consider a / to be a separator
between path components.  With tramp, that assumption
is no longer true.  Of course, I can program around
it, but I still think / is a bad choice.  What's wrong
with a : ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Integrate Tramp

[Stefan Monnier]

> I'm probably biased, but with ido, I read file names one
> character at a time, and consider a / to be a separator
> between path components.  With tramp, that assumption

Interesting.  In my own completion package (basically partial-completion-mode
enhanced with substring matching) I don't think I rely on / at all,
and use the standard file-name-parsing functions instead.

Do you remember the reason why you chose to parse the filenames by hand ?
[ I can't remember being bothered by those parsing functions, so it never
  occurred to me to parse filenames manually. ]


	Stefan

Re: Integrate Tramp

[Richard Stallman]

    Do you remember the reason why you chose to parse the filenames by hand ?

Does that really matter?  The consistency of using / only in one way
is clearly an important advantage, and not just for programs that parse
file names in the usual ways.

Re: Integrate Tramp

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> I'm probably biased, but with ido, I read file names one
> character at a time, and consider a / to be a separator
> between path components.  With tramp, that assumption
> is no longer true.  Of course, I can program around
> it, but I still think / is a bad choice.  What's wrong
> with a : ?

Tramp used to use a different filename format:

    /r:user@host:/path/to/file

I think with a method, it looked like

    /r:method#user@host:/path/to/file

but I don't quite remember anymore.  With that filename format, there
were two problems:

(1) On Microsoft Windows (hi, Bob :-) Emacs got easily confused
    between Tramp filenames and drive letters.

(2) The "/r:" prefix looked like an Ange-FTP filename.  On XEmacs,
    EFS (their equivalent of Ange-FTP) is activated quite often, so
    some EFS functions were advised to abstain from handling Tramp
    filenames.  I think there was also a problem with Emacs, but I
    forgot what it was.

With the "[]" filename format, I had problems with
file-expand-wildcards (which are solved now).

The lesson I learned from this is that it is very difficult to create
a filename format without problems.  Regardless of the choice, there
will be problems somewhere.  Of course, it could be just me...

I'm not against trying a different filename format, but I would be
really thankful if somebody else could help me test it, please.  It
would be useful to test it on the four combinations of Emacs/XEmacs,
Unix/MS Windows.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Richard Stallman]

    The lesson I learned from this is that it is very difficult to create
    a filename format without problems.  Regardless of the choice, there
    will be problems somewhere.  Of course, it could be just me...

It is premature to reach this conclusion fter trying only TWO formats.
Let's make at least one effort to try to solve all the problems that
are known.

I propose /user@host: and /user@method@host: as prefixes.
The former looks like the current remote file names,
which is intentional.  The latter is a variant which does not introduce
any additional special characters

Re: Integrate Tramp

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I propose /user@host: and /user@method@host: as prefixes.

But please, also allow just `/host:' (perhaps with appropriate
configuration required to default the user) -- I, and I suspect many
people, usually want to login as the same user...

Also, the `/user@method@host:' syntax makes it impossible to specify
_just_ a host or user and a method (or for that matter, just a method),
which seem useful for tramp (e.g., for the `sudo' methods).

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Integrate Tramp

[Jon Cast]

Miles Bader <miles@lsi.nec.co.jp> wrote:
> Richard Stallman <rms@gnu.org> writes:
> > I propose /user@host: and /user@method@host: as prefixes.
> 
> But please, also allow just `/host:' (perhaps with appropriate
> configuration required to default the user) -- I, and I suspect many
> people, usually want to login as the same user...

> Also, the `/user@method@host:' syntax makes it impossible to specify
> _just_ a host or user and a method (or for that matter, just a method),
> which seem useful for tramp (e.g., for the `sudo' methods).

Can't you let an empty user name be the same as the current user?
Then you can specify just a host and a method by saying
`/@method@host:'.  I suppose you could do the same to omit the host:
`/user@method@:'.  Just a thought.

<snip>

Jon Cast

Re: Integrate Tramp

[Miles Bader]

Jon Cast <jcast@ou.edu> writes:
> Can't you let an empty user name be the same as the current user?
> Then you can specify just a host and a method by saying
> `/@method@host:'.  I suppose you could do the same to omit the host:
> `/user@method@:'.

You could, but it would be (1) inconsistent with ange-ftp syntax, 
(2) kind of annoying to keep typing those @ signs when it's really
not necessary, and (3) ugly.

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Integrate Tramp

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I propose /user@host: and /user@method@host: as prefixes.
> The former looks like the current remote file names,
> which is intentional.  The latter is a variant which does not introduce
> any additional special characters

Actually, now that I think about it, ange-ftp _already_ uses another
character -- `#' to specify the port to use.

Here are the ange-ftp syntaxes:

     /HOST:FILENAME
     /USER@HOST:FILENAME
     /USER@HOST#PORT:FILENAME

It would actually be quite natural to put the tramp method where the
ange-ftp port is (after all the method is sort of a `port'), and it
should be unambiguous if the ange-ftp port is always a number and the
tramp method always a string [from a limited set].

Hmmm, seems quite good actually...

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: Integrate Tramp

[Richard Stallman]

    Here are the ange-ftp syntaxes:

	 /HOST:FILENAME
	 /USER@HOST:FILENAME
	 /USER@HOST#PORT:FILENAME

    It would actually be quite natural to put the tramp method where the
    ange-ftp port is (after all the method is sort of a `port'), and it
    should be unambiguous if the ange-ftp port is always a number and the
    tramp method always a string [from a limited set].

I like that idea.

Re: Integrate Tramp

[Michael Kifer]

>     Here are the ange-ftp syntaxes:
> 
> 	 /HOST:FILENAME
> 	 /USER@HOST:FILENAME
> 	 /USER@HOST#PORT:FILENAME
> 
>     It would actually be quite natural to put the tramp method where the
>     ange-ftp port is (after all the method is sort of a `port'), and it
>     should be unambiguous if the ange-ftp port is always a number and the
>     tramp method always a string [from a limited set].
> 
> I like that idea.


But ssh can also connect at a different (numeric) port (and it is often
useful). Where are you going to put this port?

Granted tramp doesn't currently support ssh connections to ports other
than the default, but if and when it will then we will be at it again,
deciding on a new syntax.

Re: Integrate Tramp

[Miles Bader]

kifer@cs.sunysb.edu (Michael Kifer) writes:
> But ssh can also connect at a different (numeric) port (and it is often
> useful). Where are you going to put this port?

   /foo@bar#ssh#443

seems pretty natural to me (in the sense that the `ssh service on port 443' 
is a subset of the `ssh service').  If `ssh' was the default I suppose
you could leave out `#ssh' and just give the port number.

-miles
-- 
We live, as we dream -- alone....

Re: Integrate Tramp

[Kai Großjohann]

Miles Bader <miles@gnu.org> writes:

> kifer@cs.sunysb.edu (Michael Kifer) writes:
>> But ssh can also connect at a different (numeric) port (and it is often
>> useful). Where are you going to put this port?
>
>    /foo@bar#ssh#443

It's probably only a matter of taste, but I prefer

    /method#user@host#port:file

A name like /a#b:c is still ambiguous, it could mean method a, host
b (and the default port), or it could mean host a, port b (and the
default method).  I suggest to use the former interpretation.

The reason I like to have the method first is that I think of the
equivalent shell command, say "ssh kai@fencepost", and then translate
it to a filename, say "/sm#kai@fencepost:/tmp".

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> It's probably only a matter of taste, but I prefer
> 
>     /method#user@host#port:file
> 
> The reason I like to have the method first is that I think of the
> equivalent shell command, say "ssh kai@fencepost", and then translate
> it to a filename, say "/sm#kai@fencepost:/tmp".

Well, which is more important -- the address, or the method used to make
the connection?  I'd say the former (the address), by far; the method is
basically just a temporary detail.

I'd also say that the most important component should come first, since
that allows users to worry about the details after they've typed in the
part that matters.

[In practice, actually, I'd hope that the defaults can be set up so the
user usually doesn't have to type the method at all.  For instance, it
could remember the method type used for a given host/user, and
automatically install that as the default for subsequent references to
the same host/user.]

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Integrate Tramp

[Stefan Monnier]

>     The lesson I learned from this is that it is very difficult to create
>     a filename format without problems.  Regardless of the choice, there
>     will be problems somewhere.  Of course, it could be just me...
> 
> It is premature to reach this conclusion fter trying only TWO formats.
> Let's make at least one effort to try to solve all the problems that
> are known.
> 
> I propose /user@host: and /user@method@host: as prefixes.
> The former looks like the current remote file names,
> which is intentional.  The latter is a variant which does not introduce
> any additional special characters

I believe some people already use /foo@bar@host because they need to
send `foo@bar' as the user name for the ftp session.  At least I seem
to remember some kind of bug report about it (IIRC, the thing
was partly working under Emacs but not XEmacs, but I might be
confused).


	Stefan

Re: Integrate Tramp

[Robert J. Chassell]

   Actually, the full tramp format seems to be

           /[method/user@host]/path/to/file

   I think using / to separate the method is a really bad idea, ...

Don't forget multi-hops!

Sometimes the full tramp format uses a colon instead of / to separate
the method.      Info File: tramp, Node: Multi-hop filename syntax
gives this example:

   /[multi/rsh:out@gate/telnet:kai@real.host]/path/to.file

You go on to suggest:

   If we adapt the idea of using the same notation as ange-ftp, i.e.
           /user@host:/path/to/file
   you could add the method as
           /[method]user@host:/
   if you really need to specify the method (using a list of host,method
   mapping and auto-detection would be much better).

Yes.  This is better.
How about the following for the entirely-manual multi-hop syntax?

   /[multi]/[rsh]out@gate.com/[telnet]kai@real.host:/path/to.file

Although I not not like putting a / between [multi] and [rsh] ,  I
am even more against these two alternatives:

   /[multi:rsh]out@...

which suggests to me that the `multi' arg applies only to the first hop

   /[multi][rsh]out@...

which looks ugly and also makes the `multi' arg appear to apply only
to the first hop.

The semi-autodedected form could be;

   /[multi]/out@gate/[telnet]kai@real.host:/path/to.file

(I am against a  /multi/  form since I can easily imagine a file name of
that sort on my local machine.)

The fully autodedected form should be:

   /out@gate.com/kai@real.host:/path/to.file

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Integrate Tramp

[Richard Stallman]

    Actually, the full tramp format seems to be

	    /[method/user@host]/path/to/file

    I think using / to separate the method is a really bad idea, as it
    makes it non-trivial to parse or split a filename.

    If we adapt the idea of using the same notation as ange-ftp, i.e.
	    /user@host:/path/to/file
    you could add the method as
	    /[method]user@host:/

I suggest user@host@method (or some other permutation)
just to reduce the number of delimiters that mean something special.

Re: Integrate Tramp

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     Actually, the full tramp format seems to be
|> 
|> 	    /[method/user@host]/path/to/file
|> 
|>     I think using / to separate the method is a really bad idea, as it
|>     makes it non-trivial to parse or split a filename.
|> 
|>     If we adapt the idea of using the same notation as ange-ftp, i.e.
|> 	    /user@host:/path/to/file
|>     you could add the method as
|> 	    /[method]user@host:/
|> 
|> I suggest user@host@method (or some other permutation)

This has the disadvantage that it becomes ambiguous if you want to leave
out one of the components.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Integrate Tramp

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> I suggest user@host@method (or some other permutation)
> just to reduce the number of delimiters that mean something special.

Why is it a problem to have all kinds of special characters before the
colon?

With Emacs 21.2, giving the filename /[x]y@z:/foo results in Emacs
trying to log in (via FTP) on the host "z" as the user "[x]y".  Does
it really matter that it is not possible anymore to specify this kind
of user name?  (I guess it would still work to specify this user name
if you also specify the method in the filename.)

Ange-FTP already uses `#', so if we must do this my suggestion is

    /method#user@host:/path/to/file

This does not increase the number of special characters.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Integrate Tramp

[Mario Lang]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> I suggest user@host@method (or some other permutation)
>> just to reduce the number of delimiters that mean something special.
>

[...]

> Ange-FTP already uses `#', so if we must do this my suggestion is
>
>     /method#user@host:/path/to/file
>
> This does not increase the number of special characters.

Is it really necessary to change tramps filename format?
As Stefan already pointed out, the internal functions for
file-name handling should be used anyway, instead of
doing a manual split on delimiters.
Please remember that bookmarks support tramp paths too.
If you are going to change the tramp path format, every user
will have to change all his bookmarks, in addition to
learn yet another (third?) way of specifying the path for tramp.

Same is for ange-ftp bookmarked paths.  They will have to
change too.


-- 
CYa,
  Mario

[jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

What do you think of this idea?

------- Start of forwarded message -------
To: gnu-emacs-bug@moderators.isc.org
From: Dan Jacobson <jidanni@deadspam.com>
Newsgroups: gnu.emacs.bug
Subject: modeline doesn't divulge buffer will go bye bye
Reply-To: Kindly_Remove_This_jidanni@ms46.hinet.net
X-Orig-NNTP-Posting-Host: 61-227-44-196.hinet-ip.hinet.net (61.227.44.196)
X-Orig-X-Trace: fu-berlin.de 1024468445 9367596 61.227.44.196 (16 [99749])
X-Orig-Path: 127.0.0.1!nobody
Sender: bug-gnu-emacs-admin@gnu.org
Date: 19 Jun 2002 10:55:49 +0800

After using this ~20 years it dawns on me: The modeline of a buffer
with an associated file and that with no associated file look the
same.  Bad.

Buffer A has maximal autosaving, you name it, cutting edge in safety,
all because it is associated with a file.

Buffer B will go bye bye when you quit emacs, no matter what you put
in it.

Their modelines will never tell you that, gotta hit C-x C-b and look around.

It seems B should have something in the modeline close to the left
edge reminding one about the situation. 

Yes I know that most are *blabla*, but I'm talking about ones I create
with C-x b blabla.  OK, I don't do that too much, but that's not the point.

The point is that the modeline tells you all the little stuff.  The
most important thing, the fact that this buffer will go bye bye
without a trace is not mentioned there!
- -- 
http://jidanni.org/ Taiwan(04)25854780

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Robert J. Chassell]

    What do you think of this idea?

        After using this ~20 years it dawns on me: The modeline of a buffer
        with an associated file and that with no associated file look the
        same.  Bad.

        ...

        The most important thing, the fact that this buffer will go
        bye bye without a trace is not mentioned there!

Interesting point!  I am not sure that this information would be
useful to me personally.  However, it is clear that this information
would be useful in general as a way of teaching people that buffers
and the files are different.  My impression is that many novices fail
to make this distinction.  Their mental model is wrong.

Perhaps we could insert a dot in a space to the left of the
`mode-line-frame-identification' segment of a mode line if the buffer
is visiting a file, and replace that glyph with a blank space if the
buffer is not associated with a file.  

I pick `dot' as the visible glyph since it is small, unobtrusive, and
should not make the mode-line appear too cramped.

Thus, in an X windowing environment, mode lines for an Emacs started with

    emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

would look like this:

       --:--        *scratch           (Lisp Interaction) L1 All

       -J:--.       .emacs             (Emacs-Lisp) L1 Top

       --:--        *mail*             (Mail) L1 All

In a character-only terminal, the mode lines would look like this:

    --1-:-- -F2     *scratch          (Lisp Interaction) L5 All

    --1J:--.-F2     .emacs            (Emacs-Lisp) L1 Top

    --1-:-- -F1     *mail*            (Mail) L1 All


Currently, the default value of the `mode-line-frame-identification' is
`" "' if you are using a window system which can show multiple frames,
or `"-%F "' on an ordinary terminal which shows only one frame at a
time.

Perhaps the `-' in `-%F ' should be removed and replaced with a blank
space if we put a dot or space in a column before.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     What do you think of this idea?
> 
>         The most important thing, the fact that this buffer will go
>         bye bye without a trace is not mentioned there!
> 

Hm, most non-file buffer names created automatically by various
packages start (and end) with an asterisk.  So for such buffers, there
typically already is a visible difference in the mode-line.

The problem is with buffers which the user creates explicitly.  Such
buffers are typically named like a file (except that they typically
don't have a file name suffix).

Personally, I choose dummy names for my own non-file buffers, so
I rarely confuse a non-file buffer with a file buffer.  Of course,
if I name my temporary buffers file.c -- I'm asking for trouble :-)

I really think this is a non-issue (it actually took Dan 20 years to
be aware that there was a problem :-)

> Perhaps we could insert a dot in a space to the left of the
> `mode-line-frame-identification' segment of a mode line if the buffer
> is visiting a file, and replace that glyph with a blank space if the
> buffer is not associated with a file.  
> 
> I pick `dot' as the visible glyph since it is small, unobtrusive, and
> should not make the mode-line appear too cramped.

I don't think this will do the trick.

For one thing, I think that if we choose to make some annotation, it
should be on the non-file buffers (which are the dangerous ones to
kill).

Maybe we could write [TMP] before the buffer name for non-file buffers.
But not do this for buffer names starting with an *.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Robert J. Chassell]

>         The most important thing, the fact that this buffer will go
>         bye bye without a trace is not mentioned there!

storm@cua.dk is persuading me that this is a non-issue.

    ... most non-file buffer names created automatically by various
    packages start (and end) with an asterisk.  So for such buffers,
    there typically already is a visible difference in the mode-line.

    The problem is with buffers which the user creates explicitly. ... 

Do people often create buffers when they mean to create files?  I
don't know.  But I don't think people make the mistake very often.

As RMS says:

    ... But the problem (if it is a problem) is with users who don't
    understand the difference.  In order to teach people to look for a
    small indicator of the difference, we need to first teach them the
    difference.

I agree.  My suggestion, a small indicator, is no good. 

Maybe this really is not a problem.  Let's see what others say.  The
best move may be to do nothing.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Stefan Monnier]

> >         The most important thing, the fact that this buffer will go
> >         bye bye without a trace is not mentioned there!
> 
> storm@cua.dk is persuading me that this is a non-issue.
> 
>     ... most non-file buffer names created automatically by various
>     packages start (and end) with an asterisk.  So for such buffers,
>     there typically already is a visible difference in the mode-line.
> 
>     The problem is with buffers which the user creates explicitly. ... 
> 
> Do people often create buffers when they mean to create files?  I
> don't know.  But I don't think people make the mistake very often.
> 
> As RMS says:
> 
>     ... But the problem (if it is a problem) is with users who don't
>     understand the difference.  In order to teach people to look for a
>     small indicator of the difference, we need to first teach them the
>     difference.
> 
> I agree.  My suggestion, a small indicator, is no good. 
> 
> Maybe this really is not a problem.  Let's see what others say.  The
> best move may be to do nothing.

Maybe we could consider the "buffer with no file" in a similar way
as some GUI text processors treat (unsaved) new documents.

So maybe we could try to mark those buffers by appending
something like "[not saved]" on the mode line.  Of course,
there's still the problem of recognizing those buffers.  Maybe

  (not (or buffer-file-name
           (string-match "\\`[ *]" (buffer-name))
           dont-say-not-saved-in-the-mode-line))

would be good enough ?


	Stefan

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Alex Schroeder]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Maybe we could consider the "buffer with no file" in a similar way
> as some GUI text processors treat (unsaved) new documents.

Maybe we should do just that -- set the buffer-file-name to
/nonexistingdrive/buffername, and set a new variable "buffer needs
file", so that Emacs will ask about saving changes (because there is a
file name associated with it), and then when the user hits C-x C-s,
Emacs recognizes that the fil name is still unknown, and asks the user
for it.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > Maybe we could consider the "buffer with no file" in a similar way
> > as some GUI text processors treat (unsaved) new documents.
> 
> Maybe we should do just that -- set the buffer-file-name to
> /nonexistingdrive/buffername, and set a new variable "buffer needs
> file", so that Emacs will ask about saving changes (because there is a
> file name associated with it), and then when the user hits C-x C-s,
> Emacs recognizes that the fil name is still unknown, and asks the user
> for it.

C-x C-s already does the right thing if buffer-file-name is nil.
I don't think we should actively support this "create buffer and then save"
model of creating files, because it suffers from the fact that it doesn't
know which major-mode to use for the buffer (plus other limitations
like the lack of auto-saving etc...).


	Stefan

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Eli Zaretskii]

On Sat, 22 Jun 2002, Stefan Monnier wrote:

> I don't think we should actively support this "create buffer and then save"
> model of creating files, because it suffers from the fact that it doesn't
> know which major-mode to use for the buffer (plus other limitations
> like the lack of auto-saving etc...).

How about adding some code so that when you kill a buffer created by the 
user (as opposed to buffers created by commands as part of their 
operation), Emacs will ask whether to save it?

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

    How about adding some code so that when you kill a buffer created by the 
    user (as opposed to buffers created by commands as part of their 
    operation), Emacs will ask whether to save it?

This might be useful for beginning users.  We could implement it with
an option to control it and see whether users want it on or off.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

				  and set a new variable "buffer needs
    file", so that Emacs will ask about saving changes (because there is a
    file name associated with it), and then when the user hits C-x C-s,
    Emacs recognizes that the fil name is still unknown, and asks the user
    for it.

C-x C-s already handles this, but maybe we ought to make C-x s do something
for them.

    Maybe we should do just that -- set the buffer-file-name to
    /nonexistingdrive/buffername,

What is the point in that?  Why not just leave it nil?

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> 				  and set a new variable "buffer needs
>     file", so that Emacs will ask about saving changes (because there is a
>     file name associated with it), and then when the user hits C-x C-s,
>     Emacs recognizes that the fil name is still unknown, and asks the user
>     for it.
>
> C-x C-s already handles this, but maybe we ought to make C-x s do something
> for them.

My bad; I was talking about C-x C-c.

>     Maybe we should do just that -- set the buffer-file-name to
>     /nonexistingdrive/buffername,
>
> What is the point in that?  Why not just leave it nil?

Start emacs -q, create new buffer using C-x b test RET.  Type
something.  Quit using C-x C-c.  Emacs quits, your edit is lost.

With my fix:  Start emacs -q, create new buffer using C-x b test RET.
Set file name using M-: (setq buffer-file-name
"/nonexistingdrive/buffername").  Type something.  Quit using C-x C-c.
Emacs asks: "Save file /nonexistingdrive/buffername? (y, n, !, ., q,
C-r or C-h)".

I think this is the kind of behaviour users expect.  Emacs will not
discard their edits, unless they are typing at a temporary buffer --
and those are buffers with names starting and ending with an asterix.
Obviously my idea leads to a weird prompt.  Perhaps using (setq
buffer-file-name (buffer-name (current-buffer))) is better.  I just
tried it and the prompt looks great.  Perhaps fixing
save-buffers-kill-emacs and friends is better.  Perhaps what I want is
that C-x b with a nonexisting buffer is equivalent to C-x C-f with
that name.  I do not know.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

    >     Maybe we should do just that -- set the buffer-file-name to
    >     /nonexistingdrive/buffername,
    >
    > What is the point in that?  Why not just leave it nil?

    Start emacs -q, create new buffer using C-x b test RET.  Type
    something.  Quit using C-x C-c.  Emacs quits, your edit is lost.

Yes, I understand the goal.  But that is a user-level behavior
you want to change.  There are many ways to do it; making
buffer-file-name non-nil is not a good way.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> Yes, I understand the goal.  But that is a user-level behavior you
> want to change.  There are many ways to do it; making
> buffer-file-name non-nil is not a good way.

I do not understand the argument, here.  Perhaps what you are saying
is that my solution does not fit the mental model developpers or users
have, ie. the semantics are somehow wrong.  Perhaps you want to say
that the result users are seeing is not caused by what they think they
did; Emacs is therefore surprising them.  If so, I do not agree.

We both agree on the goal.  I think the best semantics for this is
"When a user creates a non-temporary buffer (according to our naming
conventions), treat this buffer as an unsaved file.  It is precious,
do auto-saving."

You could then say that this is not something we want for just any
buffer a user might create.  There are lots of other buffers we want
to kill silently.

I reply to this that the code that creates temporary buffers not
following our naming conflicts are in error.  They should be fixed.
Temporary buffers should follow our naming conventions.  They are
either invisible (names start with a space) or marked as temporary
(names start and end with an asterix).  Users know this.  Users expect
this.  If they see a visible, seemingly non-temporary buffer in the
buffer list, they may expect that everything they type into it will be
auto-saved, and it will never be discarded without asking.  These
assumptions are currently violated in these rare cases.

Now we can either fix the part about killing these buffers, or add
something when creating these buffers.  I think when we fix it on the
creating side, we are fixing it on the safe side when it comes to
users.  Better safe than sorry.  I think when we fix it on the killing
of buffers side, we may find that there is yet another method of
getting rid of buffers which we did not fix (I know nothing of the
internals...).

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Miles Bader]

Alex Schroeder <alex@emacswiki.org> writes:
> We both agree on the goal.  I think the best semantics for this is
> "When a user creates a non-temporary buffer (according to our naming
> conventions), treat this buffer as an unsaved file.  It is precious,
> do auto-saving."

This is a big change in emacs' behavior.

I often create _lots_ of small random buffers with wierd names, to hold
random data (by doing `C-x C-b' and typing junk).  I expect these to go
away if I exit, and if I want something more permanent, I visit a file.

I don't mind if emacs informs me on the mode-line that my scratch
buffers won't be saved, but I _do not_ want emacs to suddenly ask me
whether I want to save each one when I exit.

> If they see a visible, seemingly non-temporary buffer in the
> buffer list, they may expect that everything they type into it will be
> auto-saved, and it will never be discarded without asking.

Who's `they'?  As you can see, I expect just the opposite.

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Alex Schroeder]

Miles Bader <miles@gnu.org> writes:

>> If they see a visible, seemingly non-temporary buffer in the
>> buffer list, they may expect that everything they type into it will be
>> auto-saved, and it will never be discarded without asking.
>
> Who's `they'?  As you can see, I expect just the opposite.

Heh, good point.  I guess "they" are the people that want to never
loose data; the kind of people who like to think of user-created
buffers as "documents" as some word processors do.  And "documents"
are things to be saved.

I also think that the distinction between ephemeral buffers and
persisten buffers (ie with files) is pretty hard to grasp -- we
currently do not have a good user interface for this.  Now adding a
confirmation is one way to go about it.  Yes, it is annoying, but at
least it is safe.  A visual indication on the modeline might be
better, but I fear people such as the OP who complained about missing
auto-save for the buffers he created will not be satisfied.

So perhaps we need a new variable that controls this?  "buffers are
documents" or something like that.  :)  I vote this be default t, to
protect newbies.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Miles Bader]

Alex Schroeder <alex@emacswiki.org> writes:
> So perhaps we need a new variable that controls this?  "buffers are
> documents" or something like that.  :)  I vote this be default t, to
> protect newbies.

That would be reasonable, as long as it's easy to turn off.

[But it might result in a lot of complaints/spurious bug reports,
depending on how many people use scratch buffers a lot like I do;
there's a _big_ community of long-time emacs users that can get
riled up by even seemingly innocuous changes]

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Francesco Potorti`]

Miles Bader <miles@gnu.org> writes:

   Alex Schroeder <alex@emacswiki.org> writes:
   > So perhaps we need a new variable that controls this?  "buffers are
   > documents" or something like that.  :)  I vote this be default t, to
   > protect newbies.
   
   That would be reasonable, as long as it's easy to turn off.

Looks like a good idea for new users, and easy to turn off for experts.
   
   [But it might result in a lot of complaints/spurious bug reports,
   depending on how many people use scratch buffers a lot like I do;
   there's a _big_ community of long-time emacs users that can get
   riled up by even seemingly innocuous changes]

Maybem, if the variable is non nil, when Emacs exits it writes something
along the lines of:

- the buffers a, b, c, d were not saved.  They are not associated to any
  file.  If you want to save them at once, you can answer `y' to the
  next question.  If you answer `n', the contents of those buffers will
  be lost forever.  If you don't want to see this message in the future,
  you can set the variable never-ask-me-stupid-questions to t.

  Save buffers not associated with a file before exit? (y/n)

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Werner LEMBERG]

> Maybem, if the variable is non nil, when Emacs exits it writes something
> along the lines of:
> 
> - the buffers a, b, c, d were not saved.  They are not associated to any
>   file.  If you want to save them at once, you can answer `y' to the
>   next question.  If you answer `n', the contents of those buffers will
>   be lost forever.  If you don't want to see this message in the future,
>   you can set the variable never-ask-me-stupid-questions to t.
> 
>   Save buffers not associated with a file before exit? (y/n)

I like that.


    Werner

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

    Maybem, if the variable is non nil, when Emacs exits it writes something
    along the lines of:
      ...
      Save buffers not associated with a file before exit? (y/n)

Simply asking a question like that, at exit time, could be a good
idea.  One more question at exit won't be terribly annoying, because
exiting is infrequent and often asks several questions.  The question
could say "Ask you now about saving buffers that have no files?".  I
think that is clear.

It could do this only if "hand-made" buffers exist, so that in many cases
you won't be asked the question at all.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>       Save buffers not associated with a file before exit? (y/n)
> 
> Simply asking a question like that, at exit time, could be a good
> idea.  One more question at exit won't be terribly annoying, because
> exiting is infrequent and often asks several questions.  The question
> could say "Ask you now about saving buffers that have no files?".  I
> think that is clear.

So how about a variable like `ask-about-saving-user-scratch-buffers',
with `nil' meaning `never' (the current behavior), `ask' meaning ask the
above question and if so treat them like unsaved file-buffers, and any
other non-nil value meaning always treat them like unsaved file-buffers.

Then we could change the default value to `ask', and people like me
that never want to could set it to nil.  I presume many people might
generally like that behavior, in which case they could set it to `t' to
avoid the unnecessary question.

-Miles
-- 
We live, as we dream -- alone....

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Alex Schroeder]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Richard Stallman <rms@gnu.org> writes:
>>       Save buffers not associated with a file before exit? (y/n)
>> 
>> Simply asking a question like that, at exit time, could be a good
>> idea.  One more question at exit won't be terribly annoying, because
>> exiting is infrequent and often asks several questions.  The question
>> could say "Ask you now about saving buffers that have no files?".  I
>> think that is clear.

One of the OP's questions remains unresolved, however.  What about
auto-save files for these buffers?

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

    One of the OP's questions remains unresolved, however.  What about
    auto-save files for these buffers?

switch-to-buffer could turn on auto-saving for them too.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

    So how about a variable like `ask-about-saving-user-scratch-buffers',
    with `nil' meaning `never' (the current behavior), `ask' meaning ask the
    above question and if so treat them like unsaved file-buffers, and any
    other non-nil value meaning always treat them like unsaved file-buffers.

That sounds good.

    That's similar to setting `buffer-offer-save' to t by default and
    forcing modes that create temporary, discardable buffers to explicitly
    set it to nil, isn't it?

It is similar, but I think it is good to have a separate option
to control this, and it is better for that option to take effect
when you exit rather than when you create the buffer.  So there needs
to be a way to distinguish these buffers from other buffers.

Perhaps a value `maybe' for `buffer-offer-save' would be the way to do
it.  When `buffer-offer-save' has that value, during saving before
exit, `offer-saving-scratch-buffers' would be obeyed.

As for the easy way to set up that value for `buffer-offer-save',
perhaps `switch-to-buffer' could do this whenever it creates a buffer.
That way, all the Lisp programs that create buffers would not be
affected.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Eli Zaretskii]

On 27 Jun 2002, Miles Bader wrote:

> So how about a variable like `ask-about-saving-user-scratch-buffers',
> with `nil' meaning `never' (the current behavior), `ask' meaning ask the
> above question and if so treat them like unsaved file-buffers, and any
> other non-nil value meaning always treat them like unsaved file-buffers.

I like this.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Juanma Barranquero]

On Wed, 26 Jun 2002 18:24:22 -0400, Richard Stallman <rms@gnu.org> wrote:

> Simply asking a question like that, at exit time, could be a good
> idea.  One more question at exit won't be terribly annoying, because
> exiting is infrequent and often asks several questions.  The question
> could say "Ask you now about saving buffers that have no files?".  I
> think that is clear.
> 
> It could do this only if "hand-made" buffers exist, so that in many cases
> you won't be asked the question at all.

That's similar to setting `buffer-offer-save' to t by default and
forcing modes that create temporary, discardable buffers to explicitly
set it to nil, isn't it?


                                                           /L/e/k/t/u

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Francesco Potorti`]

         Save buffers not associated with a file before exit? (y/n)
   
   The question could say "Ask you now about saving buffers that have no
   files?".  I think that is clear.

I find the question you propose unclear.  Maybe that depends on the
language, I don't know.  The fact is that a question that asks me if I
should be asked is somehow confusing.  So maybe reversing the question
would reteain the clarity of mine and the meaning of yours:

Discard buffers that are not associated with a file? (y/n)
   
   It could do this only if "hand-made" buffers exist, so that in many
   cases you won't be asked the question at all.
   
Sure.

But, when writing my initial suggestion, I involuntarily suggested a
wider-scope change.  Before asking those questions on exit, Emacs could
display a single window in the frame where the user typed C-x C-c, with
the list of all unsaved buffers, possibly in different columns for those
with and without an associated file.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

    Discard buffers that are not associated with a file? (y/n)

The other questions about saving all involve answering y
if you want to save.  For consistency, this one should too.

      Before asking those questions on exit, Emacs could
    display a single window in the frame where the user typed C-x C-c, with
    the list of all unsaved buffers, possibly in different columns for those
    with and without an associated file.

That could be a useful feature.  It could also list the executing
processes, if any (Emacs will ask about them too).  It could show
you ALL the reasons why you might not want to exit yet.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Jon Cast]

Alex Schroeder <alex@emacswiki.org> wrote:

> So perhaps we need a new variable that controls this?  "buffers are
> documents" or something like that.  :) I vote this be default t, to
> protect newbies.

Why not make switch-to-buffer prompt ``do you want to keep this buffer
around'' when invoked interactively?  That will:

a. Help educate users about the difference between ``buffers'' and
``documents''/``files''.

b. Help out users like Alex whose thought patterns don't mesh well
with ``always use C-x C-f to get a persistent buffer.''

Jon Cast

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Miles Bader]

Jon Cast <jcast@ou.edu> writes:
> Why not make switch-to-buffer prompt ``do you want to keep this buffer
> around'' when invoked interactively?

Because it would mind-bogglingly annoying...

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Jon Cast]

Miles Bader <miles@gnu.org> wrote:
> Jon Cast <jcast@ou.edu> writes:
> > Why not make switch-to-buffer prompt ``do you want to keep this
> > buffer around'' when invoked interactively?

> Because it would mind-bogglingly annoying...

I really doubt having to type C-x b name n rather than C-x b name
would be ``mind-bogglingly annoying''.  However, if it turns out to
really be annoying, we can always add a defcustom to turn it off.

However, new users should have the prompt on---it'll teach them the
difference between files and buffers.

> -Miles

Jon Cast

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Miles Bader]

Jon Cast <jcast@ou.edu> writes:
> I really doubt having to type C-x b name n rather than C-x b name
> would be ``mind-bogglingly annoying''.

Superfluous prompts are _always_ annoying, especially for widely used
commands like C-x b.

> However, if it turns out to
> really be annoying, we can always add a defcustom to turn it off.

Even so, it's a poor interface, for several reasons:

 (1) It asks for _every_ new scratch buffer, when seems likely that a
     given user either _usually_ wants to consider them `permanent', or
     _rarely_ does (the current default).

 (2) It asks the question too early, when the user might not really
     know whether he wants to save the buffer.

     I think that asking this sort of `decide now about the future'
     question for a command like `C-x b' (which is often used while in
     the middle of doing some task, to hold some temporary data or
     whatever) can interrupt your train of thought, and so should be
     avoided.

     Alex's suggestion, that by default emacs _assume_ that buffers
     should be saved and queried about before exiting as normal, delays
     the decision until the user has actually done his business with
     the buffer, and probably has a better idea of whether it's
     important or not.

 (3) It asks the question even for scratch buffers that are later
     explicitly killed (with C-x k), something which Alex's method
     avoids.

-miles
-- 
Run away!  Run away!

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Paul Stoeber]

On Tue, Jun 25, 2002 at 06:36:32AM +0900, Miles Bader wrote:
> Alex Schroeder <alex@emacswiki.org> writes:
> > We both agree on the goal.  I think the best semantics for this is
> > "When a user creates a non-temporary buffer (according to our naming
> > conventions), treat this buffer as an unsaved file.  It is precious,
> > do auto-saving."
> 
> This is a big change in emacs' behavior.
> 
> I often create _lots_ of small random buffers with wierd names, to hold
> random data (by doing `C-x C-b' and typing junk).  I expect these to go
> away if I exit, and if I want something more permanent, I visit a file.
> 
> I don't mind if emacs informs me on the mode-line that my scratch
> buffers won't be saved, but I _do not_ want emacs to suddenly ask me
> whether I want to save each one when I exit.
> 
> > If they see a visible, seemingly non-temporary buffer in the
> > buffer list, they may expect that everything they type into it will be
> > auto-saved, and it will never be discarded without asking.
> 
> Who's `they'?  As you can see, I expect just the opposite.

I'm satisfied with Emacs's current behaviour.

Dan Jacobson's initial message:
Dan> Buffer A has maximal autosaving, you name it, cutting edge in safety,
Dan> all because it is associated with a file.
Dan> Buffer B will go bye bye when you quit emacs, no matter what you put
Dan> in it.

The user gets to choose between the two: C-x C-f, or C-x b.
Perhaps the interactive `switch-to-buffer' should print a warning
in the minibuffer to make newbies aware of the difference.

Dan> Their modelines will never tell you that, gotta hit C-x C-b and look around.

False.  Gotta hit C-x C-s and see.  If the user is unable remember how
he created the buffer, that's not too much to ask.

Dan> Yes I know that most are *blabla*, but I'm talking about ones I create
Dan> with C-x b blabla.  OK, I don't do that too much, but that's not the point.

See Miles Bader's remark above.  It seems he _does_ do that more often
than Dan.

Dan> The point is that the modeline tells you all the little stuff.  The
Dan> most important thing, the fact that this buffer will go bye bye
Dan> without a trace is not mentioned there!

Okay, every user is entitled to worry about that point and to rate that
fact as the "most important thing".

Kevin Rodgers' reply to Dan's initial message might be a nice conclusion
of this thread:
Kevin> No, the point is that many of us have actually been using Emacs for 20
Kevin> years and not found it wanting in this regard, and those who want such a
Kevin> reminder displayed can simply customize the mode-line-format variable.
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]

    So maybe we could try to mark those buffers by appending
    something like "[not saved]" on the mode line.

"[not saved]" would give people the wrong idea; "(no file)" might be
clearer.

Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]

[Richard Stallman]

    Perhaps we could insert a dot in a space to the left of the
    `mode-line-frame-identification' segment of a mode line if the buffer
    is visiting a file, and replace that glyph with a blank space if the
    buffer is not associated with a file.  

This is so subtle that I think many users won't notice it.  If we
teach people to look for it, they can spot it.  But the problem (if it
is a problem) is with users who don't understand the difference.  In
order to teach people to look for a small indicator of the difference,
we need to first teach them the difference.  So we have not really
solved anything.

For such a mode line feature to help teach users the point about
non-file-visiting buffers, it needs to be loud enough that people who
don't know that point will notice it.

Another possible idea is to save some of these buffers in files
anyway.  Perhaps those which have "important" state in them.  We would
not save *Buffer List*, for instance, but we could save mail buffers,
shell buffers, *Compile-Log*, etc.

No calc in pretest?

[Kevin A. Burton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hey.  What happened to 'calc' in the pretest?  Calc was installed under CVS as
of 21.1.50.  Is there a reason it isn't in the pretest?  I installed the version
that was distributed under 21.1.50 and it worked fine.

Kevin (AKA missing calc)

- -- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burton@peerfear.org )
             Location - San Francisco, CA, Cell - 415.595.9965
        Jabber - burtonator@jabber.org,  Web - http://www.peerfear.org/
        GPG fingerprint: 4D20 40A0 C734 307E C7B4  DCAA 0303 3AC5 BD9D 7C4D
         IRC - openprojects.net #infoanarchy | #p2p-hackers | #reptile

All the great empires of the future will be the empires of the mind.
  -- Winston Churchill



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE9HhhWAwM6xb2dfE0RAt2jAKCdvfDLuOqzGxoroJXHMT6BNA8VWACgnnEh
fNayKXo2t9+/hj5TLHD0tI0=
=jm0x
-----END PGP SIGNATURE-----

Re: No calc in pretest?

[Eli Zaretskii]

On 29 Jun 2002 burton@openprivacy.org wrote:

> Hey.  What happened to 'calc' in the pretest?  Calc was installed under CVS as
> of 21.1.50.  Is there a reason it isn't in the pretest?

The reason is that all Emacs versions since 21.1 are bug-fix releases, so 
they are all delivered from the 21.1 release branch and don't add any 
packages that were not in 21.1.

The next major release, which will be made from the CVS head, will 
include Calc (and also Leim and the 2 ELisp manuals).

Re: No calc in pretest?

[Jon Cast]

Eli Zaretskii <eliz@is.elta.co.il> wrote:
> The reason is that all Emacs versions since 21.1 are bug-fix
> releases, so they are all delivered from the 21.1 release branch and
> don't add any packages that were not in 21.1.

> The next major release, which will be made from the CVS head, will
> include Calc (and also Leim and the 2 ELisp manuals).

Is there any chance y'all could be persuaded to number releases in a
way that'll make it obvious what's a bug fix and what's a release
from CVS head?  (I.e.,

21.4    -- Release from CVS
21.4.1  -- Bug-fix
21.4.2  -- Bug-fix
21.4.50 -- CVS
21.5    -- Release from CVS

Jon Cast

Re: No calc in pretest?

[Eli Zaretskii]

On Sun, 30 Jun 2002, Jon Cast wrote:

> Is there any chance y'all could be persuaded to number releases in a
> way that'll make it obvious what's a bug fix and what's a release
> from CVS head?

The information whether a release is a bugfix is in etc/NEWS, right at 
the beginning.  So if you need to know this, you can find the info.

As for using X.Y.Z version numbers, I don't mind, but some code in Emacs 
needs to be changed for this to work: currently, any version with 3 
numbers is assumed to be a pretest by emacsbug.el and maybe other places.
Also, loadup.el bumps up the 3rd version number automatically each time 
you rebuild the binary.

[Personally, I don't see what's the fuss about the version numbering 
(other packages, such as Texinfo, do the same as Emacs), but that's just 
me.]

Re: No calc in pretest?

[Simon Josefsson]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Sun, 30 Jun 2002, Jon Cast wrote:
>
>> Is there any chance y'all could be persuaded to number releases in a
>> way that'll make it obvious what's a bug fix and what's a release
>> from CVS head?
>
> The information whether a release is a bugfix is in etc/NEWS, right at 
> the beginning.  So if you need to know this, you can find the info.
>
> As for using X.Y.Z version numbers, I don't mind, but some code in Emacs 
> needs to be changed for this to work: currently, any version with 3 
> numbers is assumed to be a pretest by emacsbug.el and maybe other places.
> Also, loadup.el bumps up the 3rd version number automatically each time 
> you rebuild the binary.
>
> [Personally, I don't see what's the fuss about the version numbering 
> (other packages, such as Texinfo, do the same as Emacs), but that's just 
> me.]

IMHO embedding this information in the version number is useful,
etc/NEWS is not enough.  People expect that roughly the same amount
and level of modifications were made to X.Y as X.Y+1, this is not true
if CVS HEAD is released as 21.X.  I don't think the suggested
versioning scheme was good though, for the reasons you state, but
another suggestion could be to release CVS HEAD as Emacs 22.

Re: No calc in pretest?

[Jon Cast]

Simon Josefsson <jas@extundo.com> wrote:
> Eli Zaretskii <eliz@is.elta.co.il> writes:

<snip>
> > As for using X.Y.Z version numbers, I don't mind, but some code in
> > Emacs needs to be changed for this to work: currently, any version
> > with 3 numbers is assumed to be a pretest by emacsbug.el and maybe
> > other places.  Also, loadup.el bumps up the 3rd version number
> > automatically each time you rebuild the binary.

> > [Personally, I don't see what's the fuss about the version
> > numbering (other packages, such as Texinfo, do the same as Emacs),
> > but that's just me.]

> IMHO embedding this information in the version number is useful,
> etc/NEWS is not enough.  People expect that roughly the same amount
> and level of modifications were made to X.Y as X.Y+1, this is not
> true if CVS HEAD is released as 21.X.

You mean if CVS HEAD is released as 21.X in the current fashion.  My
suggestion perpetuates the present discontinuity for 21.4, but there's
no discontinuity after that (i.e., the same ``amount and level of
modifications'' would be made to 21.4 and 21.5).

> I don't think the suggested versioning scheme was good though, for
> the reasons you state, but another suggestion could be to release
> CVS HEAD as Emacs 22.

He gave two `reasons' for not using three element version numbers:

1. Some code in Emacs would have to be changed.

2. Texinfo does the same thing.

1 is valid, but minor (the CVS version of loadup.el already works, and
emacsbug.el only needs a one-line fix (probably a good idea anyway),
and I suspect any other place with the same problem has an equally
trivial fix).  Furthermore, Zaretskii has said 1 isn't a very big
problem.  So, I wouldn't bother with it now.

As for 2, I doubt as many people follow Texinfo as follow Emacs, or
that the Texinfo development is as important as Emacs
development---Texinfo seems to be more-or-less doing everything it
needs to.  So, I doubt as many people have noticed the versioning
scheme with Texinfo as with Emacs.  Just MNSHO, though.

Jon Cast

Re: No calc in pretest?

[Eli Zaretskii]

On Tue, 2 Jul 2002, Jon Cast wrote:

> 2. Texinfo does the same thing.
> [...]
> As for 2, I doubt as many people follow Texinfo as follow Emacs

Note that Texinfo was only an example; there are others.  
File/Text/Sh-utils, for example.

> that the Texinfo development is as important as Emacs
> development

IMHO, Texinfo is one of the more important GNU packages.  But I might be 
biased, since I contribute regularly to its maintenance.

Re: No calc in pretest?

[Jon Cast]

Eli Zaretskii <eliz@is.elta.co.il> wrote:
> On Tue, 2 Jul 2002, Jon Cast wrote:

> > 2. Texinfo does the same thing.
> > [...]
> > As for 2, I doubt as many people follow Texinfo as follow Emacs

> Note that Texinfo was only an example; there are others.
> File/Text/Sh-utils, for example.

Right, but my understanding is File/Text/Sh-utils have had their
interfaces more-or-less constant for basically the entire history of
GNU---somebody using v7 Unix could be sent forward in time and use the
modern GNU stuff very nearly as efficiently as you or I, and probably
wouldn't even notice the difference.  People using Emacs 20 definitely
noticed when Emacs 21 came out :) So, I still maintain Emacs is the
most eagerly followed GNU package, so it's the one where the
versioning convention causes the biggest stir.

> > that the Texinfo development is as important as Emacs development

> IMHO, Texinfo is one of the more important GNU packages.  But I
> might be biased, since I contribute regularly to its maintenance.

I agree about Texinfo's importance.  But I doubt the /ongoing
development/ of Texinfo impacts as many people as the /ongoing
development/ of Emacs.  So, fewer people notice which CVS features
haven't made it into the latest bugfix.

Jon Cast

Re: No calc in pretest?

[Eli Zaretskii]

On Wed, 3 Jul 2002, Jon Cast wrote:

> I doubt the /ongoing
> development/ of Texinfo impacts as many people as the /ongoing
> development/ of Emacs.

??? The latest 4.x series of Texinfo introduce support for HTML, XML, and 
DocBook format.  That's a revolution for such a small package, both 
feature-wise and as far as the code changes are considered.  Consider 
just the impact of the HTML split-node output on the large body of pages
which feature Web-based docs of Free Software.

Re: No calc in pretest?

[Jon Cast]

Eli Zaretskii <eliz@is.elta.co.il> wrote:
> On Wed, 3 Jul 2002, Jon Cast wrote:
> > I doubt the /ongoing development/ of Texinfo impacts as many
> > people as the /ongoing development/ of Emacs.

> ??? The latest 4.x series of Texinfo introduce support for HTML,
> XML, and DocBook format.  That's a revolution for such a small
> package, both feature-wise and as far as the code changes are
> considered.  Consider just the impact of the HTML split-node output
> on the large body of pages which feature Web-based docs of Free
> Software.

OK, I (obviously) didn't know about the output format additions.  I
retract my statements about Texinfo.  Sorry if I offended you.

However, reading the Texinfo NEWS file has produced another idea why
it doesn't get as many complaints: 4.0, 4.1, and 4.2 all have NEWS
entries beginning `new ...'.  That leads me to suspect Texinfo doesn't
have bug-fix releases, which was what my complaint about Emacs
centered around.  I don't have any complaints about Emacs's methods
for CVS or pretest version numbers, so I had mentally filtered them
out of consideration for the discussion.  Perhaps I was wrong about
that, too.

Jon Cast

Re: No calc in pretest?

[Eli Zaretskii]

> Date: Thu, 04 Jul 2002 11:37:51 -0500
> From: Jon Cast <jcast@ou.edu>
> 
> OK, I (obviously) didn't know about the output format additions.  I
> retract my statements about Texinfo.  Sorry if I offended you.

I didn't take any offence, don't worry about that.

> However, reading the Texinfo NEWS file has produced another idea why
> it doesn't get as many complaints: 4.0, 4.1, and 4.2 all have NEWS
> entries beginning `new ...'.  That leads me to suspect Texinfo doesn't
> have bug-fix releases

Version 4.2 was a bugfix release, but it also added one significant
new feature (the @copying command).

Re: No calc in pretest?

[Jon Cast]

Eli Zaretskii <eliz@is.elta.co.il> wrote w.r.t Texinfo versioning:
<snip>
> Version 4.2 was a bugfix release, but it also added one significant
> new feature (the @copying command).

I see.

Jon Cast

Re: No calc in pretest?

[Miles Bader]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> Personally, I don't see what's the fuss about the version numbering
> (other packages, such as Texinfo, do the same as Emacs), but that's
> just me.

I think moving to more conventional version numbers (e.g. adding a new
level for `minor releases') would be a good thing, because it tells
users what they're getting without them having to download the whole
package first.  Since emacs is a _very large_ download, this is actually
somewhat important (many people don't want to download a minor bugfix
release if they're happy with what they've got).

I agree that it would entail a bit of work to implement, but I doubt
it's really that much...

-Miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: No calc in pretest?

[Eli Zaretskii]

On 1 Jul 2002, Miles Bader wrote:

> I agree that it would entail a bit of work to implement, but I doubt
> it's really that much...

No, it's not much.  I just wanted to make it clear it's not zero.

Re: No calc in pretest?

[Stefan Monnier]

> The information whether a release is a bugfix is in etc/NEWS, right at
> the beginning.  So if you need to know this, you can find the info.

(with-rfc-mode
 And people SHOULD read the NEWS file anyway)

> As for using X.Y.Z version numbers, I don't mind, but some code in Emacs
> needs to be changed for this to work: currently, any version with 3
> numbers is assumed to be a pretest by emacsbug.el and maybe other places.
> Also, loadup.el bumps up the 3rd version number automatically each time
> you rebuild the binary.

We could simply decide that RC versions will be 21.1, 21.2, 21.3, 21.4
and the next trunk version will be 22.1 (at which point it will be on its
own branch for 22.2, 22.3, 22.4, ...).

> [Personally, I don't see what's the fuss about the version numbering 
> (other packages, such as Texinfo, do the same as Emacs), but that's just 
> me.]

Agreed except that the version under which the current trunk code will
be released is still unknown and that it poses problems when talking about
it in gnu.emacs.help (we've have made claims about 21.3 thinking
it would not be a bug-fix release, for example) and when writing
the :version info of defcustoms and of `make-obsolete' statements.


	Stefan

Re: No calc in pretest?

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> We could simply decide that RC versions will be 21.1, 21.2, 21.3, 21.4
> and the next trunk version will be 22.1 (at which point it will be on its
> own branch for 22.2, 22.3, 22.4, ...).

No, that would be silly.  Emacs has a good history of changes in the
major version number really meaning that major changes were made; we
shouldn't screw that up unless it's for a very good reason (and I
haven't seen one presented yet).

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
<snip>
> We could simply decide that RC versions will be 21.1, 21.2, 21.3,
> 21.4 and the next trunk version will be 22.1 (at which point it will
> be on its own branch for 22.2, 22.3, 22.4, ...).

This is, as many others have pointed out, a /bad/ idea.  The only
reason for having multiple version numbers at all, rather than number
1, 2, 3, 4, ..., is to inform users of the gravity of changes.  Making
a major release every time a release from trunk is made will destroy
that information.

Anyway, loadup.el should work without modification (or with only
slight modifications) in my scheme (it DTRT with CVS versions, which
have three element version numbers :).  And ISTR that CVS bug reports
go to a different address than pre-test bug reports, so emacsbug.el
probably needs to be fixed anyway.  So, I don't see any technical
reason not to go with three element version number for bug fix
releases, and a very good psychological/sociological reason to switch
to them.

<snip>

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Stefan Monnier]

> > We could simply decide that RC versions will be 21.1, 21.2, 21.3,
> > 21.4 and the next trunk version will be 22.1 (at which point it will
> > be on its own branch for 22.2, 22.3, 22.4, ...).
> 
> This is, as many others have pointed out, a /bad/ idea.  The only
> reason for having multiple version numbers at all, rather than number
> 1, 2, 3, 4, ..., is to inform users of the gravity of changes.  Making
> a major release every time a release from trunk is made will destroy
> that information.

As I said, I don't really buy that argument.  We'd still have this
info since 22.2 would be a bugfix release (i.e. a minor change) over
22.1.  We just wouldn't be able to differentiate between "major"
and "really major", but as I pointed out, this has already been the case
in the past, if you look at how the 19.x versions evolved.  There
was no easy way to tell if a new version was just a bugfix, a minor
improvement or a major step forward.

> Anyway, loadup.el should work without modification (or with only
> slight modifications) in my scheme (it DTRT with CVS versions, which
> have three element version numbers :).  And ISTR that CVS bug reports
> go to a different address than pre-test bug reports, so emacsbug.el
> probably needs to be fixed anyway.  So, I don't see any technical
> reason not to go with three element version number for bug fix
> releases, and a very good psychological/sociological reason to switch
> to them.

For the record, I don't have any objection to using 3-part revisions.
I just find that keeping the same 2-part revisions but just
bumping the first number more often is simpler.


	Stefan

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
<snip>
> As I said, I don't really buy that argument.  We'd still have this
> info since 22.2 would be a bugfix release (i.e. a minor change) over
> 22.1.  We just wouldn't be able to differentiate between "major" and
> "really major", but as I pointed out, this has already been the case
> in the past, if you look at how the 19.x versions evolved.  There
> was no easy way to tell if a new version was just a bugfix, a minor
> improvement or a major step forward.

My scheme allows us to differentiate `major' and `really major'.  The
fact we haven't had this information before doesn't seem to me like a
terribly compelling reason not to provide it now.

<snip>

> For the record, I don't have any objection to using 3-part revisions.
> I just find that keeping the same 2-part revisions but just
> bumping the first number more often is simpler.

Simpler, yes.  But not much simpler--probably not enough to make that
any advantage.

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Francesco Potorti`]

Jon Cast <jcast@ou.edu> writes:
   Is there any chance y'all could be persuaded to number releases in a
   way that'll make it obvious what's a bug fix and what's a release
   from CVS head?  (I.e.,
   
   21.4    -- Release from CVS
   21.4.1  -- Bug-fix
   21.4.2  -- Bug-fix
   21.4.50 -- CVS
   21.5    -- Release from CVS

I agree that this scheme or any other clear numbering scheme should be
adopted to distinguish bug-fix only releases.

Re: No calc in pretest?

[Kim F. Storm]

Francesco Potorti` <pot@gnu.org> writes:

> Jon Cast <jcast@ou.edu> writes:
>    Is there any chance y'all could be persuaded to number releases in a
>    way that'll make it obvious what's a bug fix and what's a release
>    from CVS head?  (I.e.,
>    
>    21.4    -- Release from CVS
>    21.4.1  -- Bug-fix
>    21.4.2  -- Bug-fix
>    21.4.50 -- CVS
>    21.5    -- Release from CVS
> 
> I agree that this scheme or any other clear numbering scheme should be
> adopted to distinguish bug-fix only releases.

This could also help us avoid the current hazzle of modifying the
"next version" number whenever we need to make a bug-fix release.  So
far, we have had to change the "expected" number from 21.3 to 21.4
which has an impact not only on documentation, but also on the
:version tags we put on customize options.

Alternatively, we could adapt the linux numbering where odd-minor are
development versions and even-minor are releases, e.g.

        22.1.1  -- CVS development version for 22.2
        22.1.90 -- pretest for 22.2

        22.2.1 -- initial release
        22.2.2 -- bug-fix

        22.3.1 -- CVS development version for 22.4
        22.3.90 -- pretest

        22.4.1 -- release

I switched to 22.x since introducing a new numbering scheme in the
middle of an existing non-conforming numbering scheme (as 21.x)
doesn't make sense...

Also, the number of changes since 21.1/2/3 seems to be fairly
large, so maybe it does make sense to switch to 22.x for the
next release from CVS.

The justification could be that 22.2 would be the first major release
since opening the emacs development to a broader group of developers.

The suggested numbering scheme would also allow us to make development
snapshots like 22.1.1, 22.1.2, 22.1.3 etc. to be announced on the
pretesters list for interrim feedback during development for those
interested.  [I'm not implying that we _should_ do this, just that we
_can_ do it].


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Alternatively, we could adapt the linux numbering where odd-minor are
> development versions and even-minor are releases, e.g.

What would be the point of that?  As far as I can tell, emacs simply doesn't
have `development releases', except for the flurry of quick releases for
pretesting.  For those, I think the current scheme, of using high-numbered
minor versions, is much better than the scheme linux uses.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: No calc in pretest?

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> What would be the point of that?  As far as I can tell, emacs simply
> doesn't have `development releases', except for the flurry of quick
> releases for pretesting.

But Emacs has new-feature releases and bug-fix releases.  For
example, 21.2 and 21.3 are (will be) bug-fix releases and 21.4 (I
guess) will contain new features.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: No calc in pretest?

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > Alternatively, we could adapt the linux numbering where odd-minor are
> > development versions and even-minor are releases, e.g.
> 
> What would be the point of that?  As far as I can tell, emacs simply doesn't
> have `development releases', except for the flurry of quick releases for
> pretesting.  For those, I think the current scheme, of using high-numbered
> minor versions, is much better than the scheme linux uses.

Emacs doesn't use high-numbered "minor" versions for pretests.

It uses high-numbered "minor-minor" numbers (which I think is a good
idea), but the "minor" number of the pretest is plain wrong!

The pretest  has the same minor number as the previous release, so
code cannot test emacs-minor-version for any practical purpose.

[The current CVS has emacs-minor-version == 3, although we all
expect the next release to be 21.4].

I don't know any code which breaks because of this though.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Juanma Barranquero]

On 02 Jul 2002 11:43:55 +0200, storm@cua.dk (Kim F. Storm) wrote:

> I don't know any code which breaks because of this though.

Not very significative, I know, but my .emacs is an example ;-)

I update my .emacs frequently and share it between GNU/Linux, Windows 95
and Windows 2K, and between 20.7, 21.1, 21.2, EMACS_21_1_RC and HEAD
releases/versions.

I have the following code in it, just to support checking the version
and system:

(defconst lk-emacs-sub-version
  (save-match-data
    (string-match "^[0-9]+\\.[0-9]+\\.\\([0-9]+\\)" emacs-version)
    (string-to-int (match-string 1 emacs-version)))
  "Sub-version number of this version of Emacs.")

(defun lk-check-version (major &rest arguments)
  "Check Emacs version.
By default it checks that `emacs-major-version' is greater or equal than MAJOR.
ARGUMENTS can include a minor version number (to check against `emacs-minor-version'),
a subversion number (for version numbers of the form 21.X.Y), and a test function to
replace the default >= check."
  (let ((minor nil)
        (sub nil)
        (test #'>=))
    (dolist (value arguments)
      (cond ((numberp value) (if minor (setq sub value) (setq minor value)))
            ((functionp value) (setq test value))
            (t (error "wrong argument list %s" arguments))))
    (and (funcall test emacs-major-version major)
         (or (not minor)
             (funcall test emacs-minor-version minor))
         (or (not sub)
             (funcall test lk-emacs-sub-version sub)))))

(defmacro on-system (variable &rest arguments)
  `(let ((result nil))
    (while (and arguments (not result))
      (let ((system (caar arguments)))
        (if (or (and (listp system) (memq ,variable system))
                (eq system t)
                (eq system ,variable))
            (setq result (cdar arguments))
          (setq arguments (cdr arguments)))))
    (and result (cons 'progn result))))

(defmacro on-window-system (&rest arguments)
  (on-system window-system arguments))

(defmacro on-system-type (&rest arguments)
  (on-system system-type arguments))

And then I do things like

(when (lk-check-version 21 2 50)
   ...)

which break on release renumberings. (Yeah, I use fboundp and featurep,
etc., but sometimes the changes are functional and checking the version
is the only option.)

A more logical way to numbering releases would be welcome. Still, I
dislike the even/odd convention, because it is obvious to programmers
and people who follows closely the software development cycle, but not
so obvious to casual users and/or non-programmers.

On the same vein, upping the release to 22 doesn't seem like a good idea
to me. Emacs went from 19.X to 20.X when it incorpored MULE, I think,
and from it to 21.X with a new and much better redisplay engine able to
support images and non-proportional fonts and you-name-it. Those aren't
just incremental changes. I'd expect 22.X to be the full-Unicode-support
release :)

                                                           /L/e/k/t/u

Re: No calc in pretest?

[Jon Cast]

Juanma Barranquero <lektu@terra.es> wrote:
<snip, including some nice elisp code>
> which break on release renumberings. (Yeah, I use fboundp and featurep,
> etc., but sometimes the changes are functional and checking the version
> is the only option.)

You said you use (lk-check-version 21 2 50).  So your code doesn't
break because 21.x's pre-test has version number 21.(x-1).90, right?

> A more logical way to numbering releases would be welcome. Still, I
> dislike the even/odd convention, because it is obvious to programmers
> and people who follows closely the software development cycle, but not
> so obvious to casual users and/or non-programmers.

I agree.

> On the same vein, upping the release to 22 doesn't seem like a good idea
> to me. Emacs went from 19.X to 20.X when it incorpored MULE, I think,
> and from it to 21.X with a new and much better redisplay engine able to
> support images and non-proportional fonts and you-name-it. Those aren't
> just incremental changes. I'd expect 22.X to be the full-Unicode-support
> release :)

I agree, all though I'd personally prefer 22.x to be the Gnome
integration release :)

>                                                            /L/e/k/t/u

Jon Cast

Re: No calc in pretest?

[Juanma Barranquero]

On Tue, 02 Jul 2002 15:44:59 -0500
Jon Cast <jcast@ou.edu> wrote:

> You said you use (lk-check-version 21 2 50).  So your code doesn't
> break because 21.x's pre-test has version number 21.(x-1).90, right?

No, it breaks when 21.2.50 suddenly becomes 21.3.50 ;-)

> I agree, all though I'd personally prefer 22.x to be the Gnome
> integration release :)

Even better, the Gnome Integration / Full Unicode Support release :)

Jokes aside, I agree with whomever (I think it was you) proposed a
scheme like:

21.1.1  From HEAD
21.1.2  1st bugfix release
21.1.3  2nd   "       "
        etc.
21.2.1  From HEAD
21.2.2  1st bugfix release
        etc.
22.1.1  From HEAD (new major release)

and 21.2.1.YYYYMMDD or 21.1.50, etc for pretests (I favor the YYYYMMDD
format because it is visually distinctive).

No offense intended, but jumping to 22.X, 23.X, etc too fast would make
me feel like we´re on a race against XEmacs ;-)


-- 
Juanma Barranquero <lektu@terra.es>

Re: No calc in pretest?

[Jon Cast]

> On Tue, 02 Jul 2002 15:44:59 -0500
> Jon Cast <jcast@ou.edu> wrote:

> > You said you use (lk-check-version 21 2 50).  So your code doesn't
> > break because 21.x's pre-test has version number 21.(x-1).90,
> > right?

> No, it breaks when 21.2.50 suddenly becomes 21.3.50 ;-)

I think my change (only changing to 21.3.50/21.3.0.50 when 21.2/21.2.1
is released from CVS head) should fix that.  Do you agree, in theory?

> > I agree, all though I'd personally prefer 22.x to be the Gnome
> > integration release :)

> Even better, the Gnome Integration / Full Unicode Support release :)

Either way :)

> Jokes aside, I agree with whomever (I think it was you) proposed a
> scheme like:

> 21.1.1  From HEAD
> 21.1.2  1st bugfix release
> 21.1.3  2nd   "       "
>         etc.
> 21.2.1  From HEAD
> 21.2.2  1st bugfix release
>         etc.
> 22.1.1  From HEAD (new major release)

> and 21.2.1.YYYYMMDD or 21.1.50, etc for pretests (I favor the
> YYYYMMDD format because it is visually distinctive).

I somewhat agree about the ``visually distinctive'' bit.  I will
insist on distinguishing 21.1.0.50 (CVS) from 21.1.0.90 (Pre-test)
until somebody corrects me, though.

> No offense intended, but jumping to 22.X, 23.X, etc too fast would
> make me feel like we're on a race against XEmacs ;-)

The thought had crossed my mind, but I didn't want to get into that.

> --
> Juanma Barranquero <lektu@terra.es>

Jon Cast

Re: No calc in pretest?

[Juanma Barranquero]

On Tue, 02 Jul 2002 19:52:31 -0500, Jon Cast <jcast@ou.edu> wrote:

> I think my change (only changing to 21.3.50/21.3.0.50 when 21.2/21.2.1
> is released from CVS head) should fix that.  Do you agree, in theory?

Yes.

> I somewhat agree about the ``visually distinctive'' bit.  I will
> insist on distinguishing 21.1.0.50 (CVS) from 21.1.0.90 (Pre-test)
> until somebody corrects me, though.

Fair enough.

> The thought had crossed my mind, but I didn't want to get into that.

I'm not trying to start a flamewar either :)


                                                           /L/e/k/t/u

Re: No calc in pretest?

[Eli Zaretskii]

On 2 Jul 2002 storm@cua.dk wrote:

> The pretest  has the same minor number as the previous release, so
> code cannot test emacs-minor-version for any practical purpose.

You can test whether the minor-minor version number is greater than 69.

Perhaps we should have a function for such tests.

Re: No calc in pretest?

[Jon Cast]

storm@cua.dk (Kim F. Storm) wrote:
<snip>
> It uses high-numbered "minor-minor" numbers (which I think is a good
> idea), but the "minor" number of the pretest is plain wrong!

> The pretest has the same minor number as the previous release, so
> code cannot test emacs-minor-version for any practical purpose.

Don't test emacs-minor-version.  Do a lexicographic test on
emacs-version, comparing against 21.3.90.  That'll ensure you've got
any non-CVS release containing the features of 21.4.

> [The current CVS has emacs-minor-version == 3, although we all
> expect the next release to be 21.4].

That'll make the lexicographic test fail (in general).  I, personally,
would be *much* more surprised by a system where version numbers
didn't sort lexicographically than by one in which a particular
component was `wrong'.  Not sure if this made any sense, but I hope
some of it did.

> I don't know any code which breaks because of this though.

> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

Jon Cast

Re: No calc in pretest?

[Jason Rumney]

Jon Cast <jcast@ou.edu> writes:

> storm@cua.dk (Kim F. Storm) wrote:
> <snip>
> > It uses high-numbered "minor-minor" numbers (which I think is a good
> > idea), but the "minor" number of the pretest is plain wrong!
> 
> > The pretest has the same minor number as the previous release, so
> > code cannot test emacs-minor-version for any practical purpose.
> 
> Don't test emacs-minor-version.  Do a lexicographic test on
> emacs-version, comparing against 21.3.90.  That'll ensure you've got
> any non-CVS release containing the features of 21.4.

Even better, test for features, not for version numbers.

> > I don't know any code which breaks because of this though.

Probably because in most cases code does the above.

Re: No calc in pretest?

[Juanma Barranquero]

On 02 Jul 2002 22:46:36 +0100, Jason Rumney <jasonr@gnu.org> wrote:

> Even better, test for features, not for version numbers.

Sure, but what when you need to detect a change in some interface? (For
example, that a function now admits a few more arguments). There's no
feature there.

Sometimes you just need to know the release, or do fancy tricks like

(require 'cl)
(unless (ignore-errors (whatever-func 1 2 3) t)
  (whatever-func 1 2))


                                                           /L/e/k/t/u

Re: No calc in pretest?

[Richard Stallman]

    It uses high-numbered "minor-minor" numbers (which I think is a good
    idea), but the "minor" number of the pretest is plain wrong!

It would perhaps be logical to use negative minor-minor version numbers.
I wonder if that would break anything.  We could try it.

Re: No calc in pretest?

[Jon Cast]

Richard Stallman <rms@gnu.org> wrote:
>     It uses high-numbered "minor-minor" numbers (which I think is a
>     good idea), but the "minor" number of the pretest is plain
>     wrong!

> It would perhaps be logical to use negative minor-minor version
> numbers.  I wonder if that would break anything.  We could try it.

I think this is a good idea.  The only question is what minor/micro
version number CVS versions should have under this scheme---the minor
number of the following version and a negative micro number, or the
minor number of the preceding version and a high micro number.  Hmm.

Jon Cast

Re: No calc in pretest?

[Miles Bader]

Jon Cast <jcast@ou.edu> writes:
> > It would perhaps be logical to use negative minor-minor version
> > numbers.  I wonder if that would break anything.  We could try it.
> 
> I think this is a good idea.  The only question is what minor/micro
> version number CVS versions should have under this scheme---the minor
> number of the following version and a negative micro number, or the
> minor number of the preceding version and a high micro number.  Hmm.

I assumed he meant the former, e.g. 21.4.-2.x would always be a CVS
version and 21.4.-1.y would always be a prelease (or something).

By the latter, I assume you meant e.g. 21.4.0.-x and having -X count `up
towards 0'.  The disadvantage of that is you have to pick a very high X
to avoid inadvertantly hitting 0 before you're ready...

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: No calc in pretest?

[Jon Cast]

Miles Bader <miles@gnu.org> wrote:
> Jon Cast <jcast@ou.edu> writes:

> > > It would perhaps be logical to use negative minor-minor version
> > > numbers.  I wonder if that would break anything.  We could try
> > > it.

> > I think this is a good idea.  The only question is what
> > minor/micro version number CVS versions should have under this
> > scheme---the minor number of the following version and a negative
> > micro number, or the minor number of the preceding version and a
> > high micro number.  Hmm.

> I assumed he meant the former, e.g. 21.4.-2.x would always be a CVS
> version and 21.4.-1.y would always be a prelease (or something).

This sounds reasonable.

> By the latter, I assume you meant e.g. 21.4.0.-x and having -X count
> `up towards 0'.  The disadvantage of that is you have to pick a very
> high X to avoid inadvertantly hitting 0 before you're ready...

No, by the latter I meant making the CVS preceding 21.5 21.3.50 and
making the pre-tests for 21.5 21.5.-10 (or some-such).  In other
words, should we change the version numbers for both CVS and
pre-tests, or just for pre-tests.

> -Miles

Jon Cast

Re: No calc in pretest?

[Richard Stallman]

Perhaps we can use planned gaps in minor version numbers.  For
instance, maybe the next non-bug-fix release should be Emacs 21.10.
That way, we can fix the number now.  We certainly won't get past
21.9 with bug-fix releases.

This is not fundamentally different from inserting an additional
number after the major version, as if the current version were 21.1.2
and the next non-bug-fix would be 21.2.1.  But it is less of a change
than that.  Also, we can leave a gap on occasion, but we don't have to
do it all the time.

Re: No calc in pretest?

[Jon Cast]

Richard Stallman <rms@gnu.org> wrote:
> Perhaps we can use planned gaps in minor version numbers.  For
> instance, maybe the next non-bug-fix release should be Emacs 21.10.
> That way, we can fix the number now.  We certainly won't get past
> 21.9 with bug-fix releases.

I don't like this idea---leaving gaps in the version numbers would be
confusing for users on two counts:

1. Users would think ``hey, they went from 21.3 to 21.10---did I miss
   something?''

2. Once users learn we're /intentionally/ leaving gaps in the version
   numbers, they might suspect we're trying to make it seem like more
   work is going into Emacs than actually is.  That's not good.

> This is not fundamentally different from inserting an additional
> number after the major version,

Why?  I think one is less similar to what users expect than the
current scheme, while one is more similar.  That seems like a fairly
fundamental difference.

> as if the current version were 21.1.2 and the next non-bug-fix would
> be 21.2.1.  But it is less of a change than that.

Neither one is a big change technically.  On the other hand, leaving
gaps would, IMO /seem/ like a bigger change to users, and a change for
the worse.

> Also, we can leave a gap on occasion, but we don't have to do it all
> the time.

Do you mean we would try to predict when a gap may be needed, and only
leave one then?  I fear human fallibility in that case.

Jon Cast

Re: No calc in pretest?

[Richard Stallman]

    1. Users would think ``hey, they went from 21.3 to 21.10---did I miss
       something?''

    2. Once users learn we're /intentionally/ leaving gaps in the version
       numbers, they might suspect we're trying to make it seem like more
       work is going into Emacs than actually is.  That's not good.

I don't think either of these problems will be big enough to matter.
Your impression may be different from mine, and neither of us really
knows, so I will go with my impression.

Re: No calc in pretest?

[Jon Cast]

Richard Stallman <rms@gnu.org> wrote:
<snip>
> I don't think either of these problems will be big enough to matter.
> Your impression may be different from mine, and neither of us really
> knows, so I will go with my impression.

Fair enough.

Jon Cast

Re: No calc in pretest?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Perhaps we can use planned gaps in minor version numbers.  For
> instance, maybe the next non-bug-fix release should be Emacs 21.10.
> This is not fundamentally different from inserting an additional
> number after the major version, as if the current version were 21.1.2
> and the next non-bug-fix would be 21.2.1.

I think leaving a gap is confusing; using minor-minor numbers mirrors
what's actually happening quite well, and since it's used by most
projects out there, it's very familiar and informative to users.

Since the code changes to use minor-minor numbers appear to be (heh)
minor, what's the problem with using them?

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: No calc in pretest?

[Richard Stallman]

    Since the code changes to use minor-minor numbers appear to be (heh)
    minor, what's the problem with using them?

Sorry, I don't understand which proposal you are asking about.

Re: No calc in pretest?

[Jon Cast]

Richard Stallman <rms@gnu.org> wrote:
>     Since the code changes to use minor-minor numbers appear to be
>     (heh) minor, what's the problem with using them?

> Sorry, I don't understand which proposal you are asking about.

I think he means numbering bug-fix releases as 21.x.{2,3,...}.  The
bug-fix number is the `minor-minor' number.

Jon Cast

Re: No calc in pretest?

[Francesco Potorti`]

   I think he means numbering bug-fix releases as 21.x.{2,3,...}.  The
   bug-fix number is the `minor-minor' number.

The first proposed numbering scheme was similar to this one, and in my
opinion it was the wisest.

Most software out there is released with a numbering resembling this,
and its meaning is clearer than the current one.

Re: No calc in pretest?

[Richard Stallman]

       I think he means numbering bug-fix releases as 21.x.{2,3,...}.  The
       bug-fix number is the `minor-minor' number.

We could do this starting with the next non-bug-fix release.

Re: No calc in pretest?

[Jon Cast]

Richard Stallman <rms@gnu.org> wrote:
>        I think he means numbering bug-fix releases as
>        21.x.{2,3,...}.  The bug-fix number is the `minor-minor'
>        number.

> We could do this starting with the next non-bug-fix release.

I think this is a good idea, and I volunteer (again) to do any changes
to the code which may be required to support the new scheme.

Jon Cast

Re: No calc in pretest?

[Richard Stallman]

    I think this is a good idea, and I volunteer (again) to do any changes
    to the code which may be required to support the new scheme.

You could try making that change in version.el now, and see what problems
if any you encounter.

Re: No calc in pretest?

[Kim F. Storm]

Jon Cast <jcast@ou.edu> writes:

> Richard Stallman <rms@gnu.org> wrote:
> >     It uses high-numbered "minor-minor" numbers (which I think is a
> >     good idea), but the "minor" number of the pretest is plain
> >     wrong!
> 
> > It would perhaps be logical to use negative minor-minor version
> > numbers.  I wonder if that would break anything.  We could try it.
> 
> I think this is a good idea.  The only question is what minor/micro
> version number CVS versions should have under this scheme---the minor
> number of the following version and a negative micro number, or the
> minor number of the preceding version and a high micro number.  Hmm.

The CVS version and the pretest should use the same minor number as the
next release.  That's the only consistent numbering scheme.

Maybe the CVS version could be fixed at 21.4.-99
Pretests would then use 21.4.-98, 21.4.-97, ...  etc. as a count-down
towards the final release which will be 21.4.0
Any bug fixes for that release will be 21.4.1, 21.4.2 etc.

I hope 98 pretests will be enough :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Jon Cast]

storm@cua.dk (Kim F. Storm) wrote:
<snip>
> The CVS version and the pretest should use the same minor number as
> the next release.  That's the only consistent numbering scheme.

I assume by ``consistent'' you mean ``roughly indicating the feature
set by the major/minor version number''?  In other words, interpret a
major/minor pair as indicating a feature set, and assign each release
the major/minor pair indicating its feature set most closely.  With
that meaning, I think a coherent argument could be made that we should
be conservative, and assign each release the largest major/minor pair
indicating a feature set /completely containing/ the feature set of
the release.  That would dictate giving CVS versions the minor number
of the preceding release.

For a concrete example, suppose in Emacs 21.5 customize options and
groups get a new :file keyword giving a file name to store the
option's setting in.  (I.e., Tramp could add :file ".tramp" to the
tramp defgroup, and Tramp's settings would be stored in ~/.tramp.)
Suppose this option were added on 2002 October 23.  Now, assume
someone is running CVS Emacs as of 2002 October 22 (version
21.5.-99.3).  He installs a third-party package you've released, which
wants to know if :file is supported, and use it if it is.  So, your
package tests emacs-minor-version, and determines it is 5.
Conclusion: customize supports :file.  Reality: customize doesn't
support :file.  Not good.

<snip>

> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

Jon Cast

Re: No calc in pretest?

[Kim F. Storm]

Jon Cast <jcast@ou.edu> writes:

> storm@cua.dk (Kim F. Storm) wrote:
> <snip>
> > The CVS version and the pretest should use the same minor number as
> > the next release.  That's the only consistent numbering scheme.
> 
> I assume by ``consistent'' you mean ``roughly indicating the feature
> set by the major/minor version number''?  In other words, interpret a
> major/minor pair as indicating a feature set, and assign each release
> the major/minor pair indicating its feature set most closely.  With
> that meaning, I think a coherent argument could be made that we should
> be conservative, and assign each release the largest major/minor pair
> indicating a feature set /completely containing/ the feature set of
> the release.  That would dictate giving CVS versions the minor number
> of the preceding release.

I simply don't follow...

The CVS version is working *towards* the next release, so it should
have the version number of the release it is going to be eventually.

> 
> For a concrete example, suppose in Emacs 21.5 customize options and
> groups get a new :file keyword giving a file name to store the
> option's setting in.  (I.e., Tramp could add :file ".tramp" to the
> tramp defgroup, and Tramp's settings would be stored in ~/.tramp.)
> Suppose this option were added on 2002 October 23.  Now, assume
> someone is running CVS Emacs as of 2002 October 22 (version
> 21.5.-99.3).  He installs a third-party package you've released, which
> wants to know if :file is supported, and use it if it is.  So, your
> package tests emacs-minor-version, and determines it is 5.
> Conclusion: customize supports :file.  Reality: customize doesn't
> support :file.  Not good.

That's not a valid argument IMHO!

People using the CVS emacs version should be expecting that things
will break from time to time if they don't update regularly.

We cannot and should not be backwards compatible with "yesterday's
CVS", and there is no reason to be able to differentiate!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Jon Cast]

storm@cua.dk (Kim F. Storm) wrote:
> Jon Cast <jcast@ou.edu> writes:
<snip>
> > I assume by ``consistent'' you mean ``roughly indicating the
> > feature set by the major/minor version number''?  In other words,
> > interpret a major/minor pair as indicating a feature set, and
> > assign each release the major/minor pair indicating its feature
> > set most closely.  With that meaning, I think a coherent argument
> > could be made that we should be conservative, and assign each
> > release the largest major/minor pair indicating a feature set
> > /completely containing/ the feature set of the release.  That
> > would dictate giving CVS versions the minor number of the
> > preceding release.

> I simply don't follow...

I rather expected that.  (I wasn't sure I followed it myself, but I
figured I'd try it.)

> The CVS version is working *towards* the next release, so it should
> have the version number of the release it is going to be eventually.

I agree, because of the argument you give below.

> > For a concrete example, suppose in Emacs 21.5 customize options
> > and groups get a new :file keyword giving a file name to store the
> > option's setting in.  (I.e., Tramp could add :file ".tramp" to the
> > tramp defgroup, and Tramp's settings would be stored in ~/.tramp.)
> > Suppose this option were added on 2002 October 23.  Now, assume
> > someone is running CVS Emacs as of 2002 October 22 (version
> > 21.5.-99.3).  He installs a third-party package you've released,
> > which wants to know if :file is supported, and use it if it is.
> > So, your package tests emacs-minor-version, and determines it is
> > 5.  Conclusion: customize supports :file.  Reality: customize
> > doesn't support :file.  Not good.

> That's not a valid argument IMHO!

> People using the CVS emacs version should be expecting that things
> will break from time to time if they don't update regularly.

That's probably true.

> We cannot and should not be backwards compatible with "yesterday's
> CVS", and there is no reason to be able to differentiate!

You may well be right, and I hereby abandon the idea of giving CVS the
minor version number of the preceding release.

> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

Jon Cast

Re: No calc in pretest?

[Richard Stallman]

    Suppose this option were added on 2002 October 23.  Now, assume
    someone is running CVS Emacs as of 2002 October 22 (version
    21.5.-99.3).  He installs a third-party package you've released, which
    wants to know if :file is supported, and use it if it is.

People using CVS versions must expect to encounter various transient
problems.  They should always try updating to see if the problem goes
away.

Re: No calc in pretest?

[Jon Cast]

Message from Richard Stallman <rms@gnu.org> wrote:
>     Suppose this option were added on 2002 October 23.  Now, assume
>     someone is running CVS Emacs as of 2002 October 22 (version
>     21.5.-99.3).  He installs a third-party package you've released,
>     which wants to know if :file is supported, and use it if it is.

> People using CVS versions must expect to encounter various transient
> problems.  They should always try updating to see if the problem
> goes away.

Now that I think about it, you're right---CVS's purpose is to
facilitate regular updates, so we can expect those to be employed by
anyone using CVS :)

Jon Cast

Re: No calc in pretest?

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> I hope 98 pretests will be enough :-)

There was Emacs 21.0.106.  So 98 is problematic.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: No calc in pretest?

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > I hope 98 pretests will be enough :-)
> 
> There was Emacs 21.0.106.  So 98 is problematic.

It started from 90, so that's only 16 pretests.

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: No calc in pretest?

[Kai Großjohann]

Miles Bader <miles@gnu.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> > I hope 98 pretests will be enough :-)
>> 
>> There was Emacs 21.0.106.  So 98 is problematic.
>
> It started from 90, so that's only 16 pretests.

Arf.  Sorry.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: No calc in pretest?

[Richard Stallman]

    Maybe the CVS version could be fixed at 21.4.-99
    Pretests would then use 21.4.-98, 21.4.-97, ...  etc. as a count-down
    towards the final release which will be 21.4.0
    Any bug fixes for that release will be 21.4.1, 21.4.2 etc.

This might be a good idea.  (I would probably start at -10 rather than
-99.)

To avoid confusion, the real release should be .1, not .0.

Re: No calc in pretest?

[Jon Cast]

Richard Stallman <rms@gnu.org> wrote:
>     Maybe the CVS version could be fixed at 21.4.-99 Pretests would
>     then use 21.4.-98, 21.4.-97, ...  etc. as a count-down towards
>     the final release which will be 21.4.0 Any bug fixes for that
>     release will be 21.4.1, 21.4.2 etc.

> This might be a good idea.  (I would probably start at -10 rather
> than -99.)

I agree.  However, IMO the first pretest should be -20 or -30 rather
than -10 --- from what I understand, Emacs 21 went up to pretest 106
from 90, which makes 17 pretests.

I assume CVS would be -50 or some such?

> To avoid confusion, the real release should be .1, not .0.

I'm not sure I follow this.  Confusion about what?

Jon Cast

Re: No calc in pretest?

[Eli Zaretskii]

On Mon, 8 Jul 2002, Jon Cast wrote:

> > This might be a good idea.  (I would probably start at -10 rather
> > than -99.)
> 
> I agree.  However, IMO the first pretest should be -20 or -30 rather
> than -10 --- from what I understand, Emacs 21 went up to pretest 106
> from 90, which makes 17 pretests.

I'd suggest -30 or even -40 for major releases.  Then you have the 
flexibility to bump from -30 to -20 if the number of problems in -30 is 
not large.

This corresponds to what was used in the past: major releases started 
with a .70 or even .65 minor-minor version.

Re: No calc in pretest?

[Richard Stallman]

    > To avoid confusion, the real release should be .1, not .0.

    I'm not sure I follow this.  Confusion about what?

People expect a real release to be ".1", and may be surprised
by a release called "22.0" or "21.4.0".

Re: No calc in pretest?

[Jon Cast]

Richard Stallman <rms@gnu.org> wrote:
>     > To avoid confusion, the real release should be .1, not .0.

>     I'm not sure I follow this.  Confusion about what?

> People expect a real release to be ".1", and may be surprised by a
> release called "22.0" or "21.4.0".

I see.  I didn't realize that (it is not of course a general rule).
If that is currently the rule for Emacs, it should of course be
preserved.

Jon Cast

Re: No calc in pretest?

[Eli Zaretskii]

On 2 Jul 2002, Miles Bader wrote:

> I think the current scheme, of using high-numbered
> minor versions, is much better than the scheme linux uses.

Yes, I agree.

Btw, there are other GNU projects that use the same numbering scheme 
for alpha versions.

Re: No calc in pretest?

[Eli Zaretskii]

On 2 Jul 2002 storm@cua.dk wrote:

> This could also help us avoid the current hazzle of modifying the
> "next version" number whenever we need to make a bug-fix release.  So
> far, we have had to change the "expected" number from 21.3 to 21.4
> which has an impact not only on documentation, but also on the
> :version tags we put on customize options.

From my experience of making these version changes, it's a non-issue.

> Also, the number of changes since 21.1/2/3 seems to be fairly
> large, so maybe it does make sense to switch to 22.x for the
> next release from CVS.

I don't have any strong feelings, but IMHO changing the major version 
number after only 3 releases is generally undesirable.  So far, the major 
version changed when some significant new feature was added:

   v19 - support for X
   v20 - m17n
   v21 - new display engine

If we follow this, v22 should be the Unicode-based Emacs, not some 
intermediate release.

Re: No calc in pretest?

[Stefan Monnier]

> I don't have any strong feelings, but IMHO changing the major version
> number after only 3 releases is generally undesirable.

I don't see any good reason why this should be so.

> So far, the major 
> version changed when some significant new feature was added:
> 
>    v19 - support for X
>    v20 - m17n
>    v21 - new display engine

What about between v17 and v18 ?
What about between v3 and v4 ?
What is the relevance of all of it anyway.
It's merely psychological and not even very strongly felt by anyone anyway.
To me (and many other people I know), the differences between v19
and v21 are not that significant since I don't use anything else
than latin-1 and my bufffers are 99.9% filled with the same
misc-fixed-semicondensed.  The jump from 19.28 to 19.29 was more
significant to me in some regards.

> If we follow this, v22 should be the Unicode-based Emacs, not some
> intermediate release.

Again, I don't see any reason why this should be so.
If it's more convenient to name the current trunk 22.0, then I think it
should be done.


	Stefan

Re: No calc in pretest?

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> If it's more convenient to name the current trunk 22.0, then I think it
> should be done.

No one has presented a good reason why it would be more convenient either.

Kim said:
> I switched to 22.x since introducing a new numbering scheme in the
> middle of an existing non-conforming numbering scheme (as 21.x)
> doesn't make sense...

but I can't see any reason why that's true, since it isn't really a `new
numbering scheme'; it's more of a minor tweak.  The only thing people
really depend on about future emacs version numbers is that they
increase, and that they `make sense', and I don't think it's any more
confusing to start using minor-minor release numbers with 21.4.x than it
would be with 22.1.x -- whereas I guarantee that people _will_ wonder
`Whoa, emacs 22 already!  What great feature did they add?!', and go
away disappointed if they hear it's `just a version number adjustment.'

-miles
-- 
I have seen the enemy, and he is us.  -- Pogo

Re: No calc in pretest?

[Stefan Monnier]

> > If it's more convenient to name the current trunk 22.0, then I think it
> > should be done.
> No one has presented a good reason why it would be more convenient either.

I don't necessarily claim that the :version problem in defcustom
and in make-obsolete is "a good reason", but I think it is an annoyance.
I'd much rather fix that annoyance than stick to some vague notion
of "significant change".


	Stefan

Re: No calc in pretest?

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> I don't necessarily claim that the :version problem in defcustom
> and in make-obsolete is "a good reason", but I think it is an annoyance.

What is the `:version problem'?  As far as I can see, such comparisons
should still work fine because no existing components have changed
meaning.  Of course the version-number-comparison function will have to
be updated for minor-minor components, but that seems unrelated.

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: No calc in pretest?

[Stefan Monnier]

> > I don't necessarily claim that the :version problem in defcustom
> > and in make-obsolete is "a good reason", but I think it is an annoyance.
> What is the `:version problem'?

That when it was decided that 21.3 would also be a bugfix release,
several :version and make-obsolete statements had to be updated
to say "21.4" instead of "21.3".
A quick grep shows that not all of the occurrences have been updated yet.


	Stefan

Re: No calc in pretest?

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> That when it was decided that 21.3 would also be a bugfix release,
> several :version and make-obsolete statements had to be updated
> to say "21.4" instead of "21.3".

But that's unrelated to whether the next trunk release is 22.1 or 21.4
(and the adoption of minor-minor version numbers will get rid of this
problem in the future, regardless of what the next trunk release is
called).  [Well, not entirely unrelated -- if we were to make _another_
bug release before 21.4, we'd have to switch the bugfix branch to the
new version numbering scheme.]

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: No calc in pretest?

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > That when it was decided that 21.3 would also be a bugfix release,
> > several :version and make-obsolete statements had to be updated
> > to say "21.4" instead of "21.3".
> 
> But that's unrelated to whether the next trunk release is 22.1 or 21.4
> (and the adoption of minor-minor version numbers will get rid of this
> problem in the future, regardless of what the next trunk release is
> called).

The proposition was *instead* of minor-minor version numbers.
I.e. just make the MM part of NN.MM be a bugfix-release-number and
whenever a release is not bugfix only, then bump up the NN.

Of course, another solution is to not do any parallel development on
several branches at the same time.
Parallel development on several branches is extra work and I'm not
sure whether it's worth it for us to do it.


	Stefan

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
<snip>
> The proposition was *instead* of minor-minor version numbers.
> I.e. just make the MM part of NN.MM be a bugfix-release-number and
> whenever a release is not bugfix only, then bump up the NN.

But your argument about :version has no bearing on whether to use
minor-minor version numbers.

<snip>

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
<snip>
> That when it was decided that 21.3 would also be a bugfix release,
> several :version and make-obsolete statements had to be updated to
> say "21.4" instead of "21.3".  A quick grep shows that not all of
> the occurrences have been updated yet.

You do realize this cannot happen with either my scheme or yours,
right?  So it has nothing to do with which scheme is adopted.

(If Emacs had been using my scheme from 21.1, 21.4 would have started
and ended life as 21.2, and the decision to make another pre-release
would have only meant releasing a 21.1.2 rather than just a 21.1.1.
So no :version tags would need to change.)

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Stefan Monnier]

> > That when it was decided that 21.3 would also be a bugfix release,
> > several :version and make-obsolete statements had to be updated to
> > say "21.4" instead of "21.3".  A quick grep shows that not all of
> > the occurrences have been updated yet.
> 
> You do realize this cannot happen with either my scheme or yours,
> right?  So it has nothing to do with which scheme is adopted.

I understand that my scheme is AA.BB while yours is A.A.BB.
The use of BB as the "bugfix" indicator is common to both proposals
and that's the one I mostly care about.

If people prefer using CC.AA.BB, that's fine by me, but as far as I'm concerned
the distinction between major and really-major releases is too fuzzy
to be worth the trouble.

All I care about is that each CVS branch have its own "major" number
so it is independent from the others.  Whether those numbers
look like AA or A.A (i.e. "22" or "22.2") is not really important
to me and (I believe) in general.
Since I find it unimportant, I don't think it's worth the trouble
(since it would be a change that requires hacking).


	Stefan

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
> > > That when it was decided that 21.3 would also be a bugfix
> > > release, several :version and make-obsolete statements had to be
> > > updated to say "21.4" instead of "21.3".  A quick grep shows
> > > that not all of the occurrences have been updated yet.

> > You do realize this cannot happen with either my scheme or yours,
> > right?  So it has nothing to do with which scheme is adopted.

> I understand that my scheme is AA.BB while yours is A.A.BB.  The use
> of BB as the "bugfix" indicator is common to both proposals and
> that's the one I mostly care about.

I'm confused: if you `mostly care about' BB, why spend so much time
arguing with Miles and me?

> If people prefer using CC.AA.BB, that's fine by me, but as far as
> I'm concerned the distinction between major and really-major
> releases is too fuzzy to be worth the trouble.

What trouble?  The trouble of converting to a three-element system
(i.e., using fully general lexical ordering rather than un-rolling the
loops), or the trouble of changing things if what we thought was x.y
turns out to be (x+1).1?  Nobody's asking you to take any trouble
about the first case, and I doubt the second case will be important
enough to bother you.

> All I care about is that each CVS branch have its own "major" number
> so it is independent from the others.  Whether those numbers look
> like AA or A.A (i.e. "22" or "22.2") is not really important to me
> and (I believe) in general.

This is something I've never understood: why do people who don't care
about the answer spend so much time on the question?  Why not just let
those who do care decide?

> Since I find it unimportant, I don't think it's worth the trouble
> (since it would be a change that requires hacking).

This change should require 0 trouble to you, since no one's asking
anything of you.  I'll do all the work to set it up, and I don't think
any further work will be required.  How can it not be worth that to
you?

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
> > > If it's more convenient to name the current trunk 22.0, then I
> > > think it should be done.

> > No one has presented a good reason why it would be more convenient
> > either.

> I don't necessarily claim that the :version problem in defcustom and
> in make-obsolete is "a good reason", but I think it is an annoyance.
> I'd much rather fix that annoyance than stick to some vague notion
> of "significant change".

Why doesn't using 21.4 for the next release from head and 21.4.x for
bug-fix releases after that fix you :version complaint?  Even if the
next release from head turns out to be 21.5, the release from head
after that still cannot be anything but 21.6 (or 22, but it's only 22
if we know ahead of time it's a major change).  So, the problem will
be as fixed as possible at some point in the future with my
suggestion.  Your suggestion may fix it faster, but it'll also confuse
more users.

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Simon Josefsson]

Miles Bader <miles@gnu.org> writes:

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>> If it's more convenient to name the current trunk 22.0, then I think it
>> should be done.
>
> No one has presented a good reason why it would be more convenient either.

One reason is that we don't have to update :version fields and
documentation if there is a well defined versioning scheme.

> Kim said:
>> I switched to 22.x since introducing a new numbering scheme in the
>> middle of an existing non-conforming numbering scheme (as 21.x)
>> doesn't make sense...
>
> but I can't see any reason why that's true, since it isn't really a `new
> numbering scheme'; it's more of a minor tweak.  The only thing people
> really depend on about future emacs version numbers is that they
> increase, and that they `make sense', and I don't think it's any more
> confusing to start using minor-minor release numbers with 21.4.x than it
> would be with 22.1.x -- whereas I guarantee that people _will_ wonder
> `Whoa, emacs 22 already!  What great feature did they add?!', and go
> away disappointed if they hear it's `just a version number adjustment.'

But there are major changes in CVS HEAD, that is the whole point of
calling it Emacs 22, which I think is a good idea.  Releasing CVS HEAD
as 21.4 would be a mistake, as users would think "Pah, emacs 21.4, I
already have 21.2 and it works, I won't bother upgrading.".

What is major and what isn't major is not something objectively true.
Many users probably don't care if Emacs uses MULE or Unicode
internally even though it is major work, and also many users regards
window transparency as something major altough it is little work.

Having faster development cycles has always been one of my gripes with
emacs, new features shouldn't have to wait 3-4 years.

Re: No calc in pretest?

[Eli Zaretskii]

On Tue, 2 Jul 2002, Simon Josefsson wrote:

> One reason is that we don't have to update :version fields and
> documentation if there is a well defined versioning scheme.

I sincerely doubt that the version-update problem will go away with 
_any_ versioning scheme.

If we want to solve this annoyance, we should find a solution for it that 
doesn't require manual work when versions change numbers.

> Releasing CVS HEAD
> as 21.4 would be a mistake, as users would think "Pah, emacs 21.4, I
> already have 21.2 and it works, I won't bother upgrading.".

I'd expect them to read NEWS first (it's normally linked from the Emacs 
Web page), and only then make up their minds.

> Having faster development cycles has always been one of my gripes with
> emacs, new features shouldn't have to wait 3-4 years.

I'd say that's an exaggeration: not even 1 year has passed since v21.1, 
so new features in CVS head now could be available within the next 6 
months, say.  That's slightly more than 1 year since 21.1, the last 
non-bugfix release.

Re: No calc in pretest?

[Stefan Monnier]

> > One reason is that we don't have to update :version fields and
> > documentation if there is a well defined versioning scheme.
> 
> I sincerely doubt that the version-update problem will go away with 
> _any_ versioning scheme.

It will "go away" if the versioning scheme ensures that the version
number of a release can be determined long before the release happens
(i.e. is independent of any other release that might happen in the
mean time).


	Stefan

Re: No calc in pretest?

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > > One reason is that we don't have to update :version fields and
> > > documentation if there is a well defined versioning scheme.
> > 
> > I sincerely doubt that the version-update problem will go away with 
> > _any_ versioning scheme.
> 
> It will "go away" if the versioning scheme ensures that the version
> number of a release can be determined long before the release happens
> (i.e. is independent of any other release that might happen in the
> mean time).

Exactly.  While our current numbering scheme cannot ensure that,
other numbering schemes (some of which have been suggested here)
can easily ensure this.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
> > > One reason is that we don't have to update :version fields and
> > > documentation if there is a well defined versioning scheme.

> > I sincerely doubt that the version-update problem will go away with
> > _any_ versioning scheme.

> It will "go away" if the versioning scheme ensures that the version
> number of a release can be determined long before the release happens
> (i.e. is independent of any other release that might happen in the
> mean time).

Which both schemes accomplish.

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Eli Zaretskii]

On Tue, 2 Jul 2002, Stefan Monnier wrote:

> > > One reason is that we don't have to update :version fields and
> > > documentation if there is a well defined versioning scheme.
> > 
> > I sincerely doubt that the version-update problem will go away with 
> > _any_ versioning scheme.
> 
> It will "go away" if the versioning scheme ensures that the version
> number of a release can be determined long before the release happens
> (i.e. is independent of any other release that might happen in the
> mean time).

That's exactly what I doubt will ever happen.  Humans are too imperfect.

Re: No calc in pretest?

[Kim F. Storm]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Tue, 2 Jul 2002, Simon Josefsson wrote:
> 
> > One reason is that we don't have to update :version fields and
> > documentation if there is a well defined versioning scheme.
> 
> I sincerely doubt that the version-update problem will go away with 
> _any_ versioning scheme.
> 
> If we want to solve this annoyance, we should find a solution for it that 
> doesn't require manual work when versions change numbers.

The aim should be to use a numbering scheme which does not require us
to change the numbers once we have decided on the number for the next
"major" release.  And we should be able to make that decision
immediately after making a release.  

And it must allow us to make interrim bug-fix releases.

Stefan's proposal to simply increment the major number for every
non-bugfix release, and the minor number for bug-fix releases is both
simple and straight-forward to implement.

> > Having faster development cycles has always been one of my gripes with
> > emacs, new features shouldn't have to wait 3-4 years.
> 
> I'd say that's an exaggeration: not even 1 year has passed since v21.1, 
> so new features in CVS head now could be available within the next 6 
> months, say.  That's slightly more than 1 year since 21.1, the last 
> non-bugfix release.

Incrementing the major number every 18 months doesn't seem
unreasonable to me.  I'd assume that "enough" changes have been made
in those 18 months to warrant a new "major" release.  Maybe not a
quantum leap, but at least significantly different from the previous
major release.  

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Simon Josefsson]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>> Having faster development cycles has always been one of my gripes with
>> emacs, new features shouldn't have to wait 3-4 years.
>
> I'd say that's an exaggeration: not even 1 year has passed since v21.1, 
> so new features in CVS head now could be available within the next 6 
> months, say.  That's slightly more than 1 year since 21.1, the last 
> non-bugfix release.

I based it on what can be verified, released versions:

Emacs 13: cannot find traces of this
Emacs 14: 1984?
Emacs 15: 1985
Emacs 16: 1986
Emacs 17: 1986
Emacs 18.1: earlier than 1986-11-23?
Emacs 18.31: 1986-11-23
Emacs 18.59: 1992-10-30
Emacs 19.1: between 1992-10-30 and 1993-05-22?
Emacs 19.7: 1993-05-22
Emacs 19.34b: 1996-08-21
Emacs 20.1: 1997-09-15
Emacs 21.1: 2001-10-20

3-4 year seem to be optimistic, rather than exaggerated, if looking at
the last 15 years.

Of course, I hope that CVS HEAD will be out soon, but I'll trust you
when I see it. ;-)

Re: No calc in pretest?

[Eli Zaretskii]

> From: Simon Josefsson <jas@extundo.com>
> Date: Fri, 05 Jul 2002 19:51:36 +0200
> 
> >> Having faster development cycles has always been one of my gripes with
> >> emacs, new features shouldn't have to wait 3-4 years.
> >
> > I'd say that's an exaggeration: not even 1 year has passed since v21.1, 
> > so new features in CVS head now could be available within the next 6 
> > months, say.  That's slightly more than 1 year since 21.1, the last 
> > non-bugfix release.
> 
> I based it on what can be verified, released versions:
> 
> Emacs 13: cannot find traces of this
> Emacs 14: 1984?
> Emacs 15: 1985
> Emacs 16: 1986
> Emacs 17: 1986
> Emacs 18.1: earlier than 1986-11-23?
> Emacs 18.31: 1986-11-23
> Emacs 18.59: 1992-10-30
> Emacs 19.1: between 1992-10-30 and 1993-05-22?
> Emacs 19.7: 1993-05-22
> Emacs 19.34b: 1996-08-21
> Emacs 20.1: 1997-09-15
> Emacs 21.1: 2001-10-20
> 
> 3-4 year seem to be optimistic, rather than exaggerated, if looking at
> the last 15 years.

This seems to be some misunderstanding: new features do not wait until
the next major version, they wait until the next _non-bugfix_ release.
In other words, the new features now in CVS head will not need to wait
until Emacs 22.1.

Re: No calc in pretest?

[Jon Cast]

Simon Josefsson <jas@extundo.com> wrote:
> Miles Bader <miles@gnu.org> writes:

> > "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> >> If it's more convenient to name the current trunk 22.0, then I
> >> think it should be done.

> > No one has presented a good reason why it would be more convenient
> > either.

> One reason is that we don't have to update :version fields and
> documentation if there is a well defined versioning scheme.

The following:

x.y.0                   is a release from head
x.y.z    (1 <= z < 50)  is a bug-fix release
x.y.z.90 (1 <= z < 50)  is a bug-fix pre-test
x.y.z    (50 <= z < 70) is CVS
x.y.z    (70 <= z < 99) is a head pre-test

is well-defined.  Is that not sufficient for your purposes?

<snip>

> But there are major changes in CVS HEAD, that is the whole point of
> calling it Emacs 22, which I think is a good idea.  Releasing CVS
> HEAD as 21.4 would be a mistake, as users would think "Pah, emacs
> 21.4, I already have 21.2 and it works, I won't bother upgrading.".

I don't think the changes that have been made are `major'.  `Major'
means something internally important; the changes between 21.3 and
21.4 are mostly external and either cosmetic or pure additions (i.e.,
everything in 21.1 is un-affected).  There are `many' changes, but we
expect that, right?

> What is major and what isn't major is not something objectively
> true.  Many users probably don't care if Emacs uses MULE or Unicode
> internally even though it is major work, and also many users regards
> window transparency as something major altough it is little work.

Well, not unless RMS says something is major or not.  He's the
maintainer, I think the determination of what is major should be left
up to him.

> Having faster development cycles has always been one of my gripes
> with emacs, new features shouldn't have to wait 3-4 years.

And calling the next release 22.0 fixes this how?

Jon Cast

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> > I don't have any strong feelings, but IMHO changing the major
> > version number after only 3 releases is generally undesirable.

> I don't see any good reason why this should be so.

I don't see any good reason why it shouldn't be so, and I don't see
any bad reason either.  Even if you don't think tradition, conformance
to the cultural expectations of Free Software users, etc. are good
reasons, you have to admit they're bad reasons :)

> > So far, the major version changed when some significant new
> > feature was added:

> >    v19 - support for X
> >    v20 - m17n
> >    v21 - new display engine

> What about between v17 and v18 ?

I don't think either of those existed.

> What about between v3 and v4 ?

I know those didn't exist.

> What is the relevance of all of it anyway.

Version number carry information for users, even more than for the
system (although the presence of bug fix releases does change that
slightly.  Users aren't expecting bug fix releases, so they aren't
expecting that change, though.)  How users will read version numbers
is very important to how they should be set up, just like how users
will read documentation is very important to how it should be set up.

> It's merely psychological and not even very strongly felt by anyone
> anyway.

I feel it very strongly.

> To me (and many other people I know), the differences between v19
> and v21 are not that significant since I don't use anything else
> than latin-1 and my bufffers are 99.9% filled with the same
> misc-fixed-semicondensed.  The jump from 19.28 to 19.29 was more
> significant to me in some regards.

Are you arguing we don't have a fixed frame of reference to judge
``major'' from?  I think we do (or should): what is a significant step
toward the goals of the Emacs maintainer?  Those steps merit major
version number bumps.  Others don't.

> > If we follow this, v22 should be the Unicode-based Emacs, not some
> > intermediate release.

> Again, I don't see any reason why this should be so.  If it's more
> convenient to name the current trunk 22.0, then I think it should be
> done.

I don't think we have /any/ gain in convenience labeling the current
trunk 22.0 over 21.4.  And users expect major releases to be, well,
major.  What reason does Emacs have to dis-regard that?

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Stefan Monnier]

> > > I don't have any strong feelings, but IMHO changing the major
> > > version number after only 3 releases is generally undesirable.
> > I don't see any good reason why this should be so.
> I don't see any good reason why it shouldn't be so, and I don't see
> any bad reason either.  Even if you don't think tradition, conformance
> to the cultural expectations of Free Software users, etc. are good
> reasons, you have to admit they're bad reasons :)

What's the fundamental difference betweeen 3 or 4 revisions
and 7 (as in the Emacs-20 line) ?
Adding cua, tramp, ido, the elisp manual, calc, leim and more isn't enough
to justify bumping the major revision counter ?  Why not ?

> > What about between v17 and v18 ?
> I don't think either of those existed.

I actually don't know but I'd be surprised if you're right.
They might have never been released, but I expected they existed.

> > What about between v3 and v4 ?
> I know those didn't exist.

I again think you're wrong.

> > What is the relevance of all of it anyway.
> Version number carry information for users, even more than for the
> system (although the presence of bug fix releases does change that
> slightly.  Users aren't expecting bug fix releases, so they aren't
> expecting that change, though.)  How users will read version numbers
> is very important to how they should be set up, just like how users
> will read documentation is very important to how it should be set up.

Yes, it has some importance.  It's important for people to know whether
it's just a bugfix release or not.  But as for what defines a major
change, as I said, this is very subjective.
In the past, Emacs revision numbers have been completely useless as
"bugfix" indicators and have only been mildly useful as featureset
predictors.  And I haven't heard many complaints about it,
and the only complaints I heard were about distinguishing
bugfix-releases, which my 2-part scheme handles just fine.

> Are you arguing we don't have a fixed frame of reference to judge
> ``major'' from?  I think we do (or should): what is a significant step
> toward the goals of the Emacs maintainer?  Those steps merit major
> version number bumps.  Others don't.

The only definition of "major" that I could find compelling and that
seems to corresponds to past practices is "a major rework of the C code".
That does not necessarily have anything to do with what users perceive
in term of features.
So if you consider major release numbers as indicators of "probably buggy
because it has a lot of new code", I could agree.  But claiming that
we should distinguish between the jump from 19.28->19.29 and 19.34->20.1
in terms of features is just not right, because to most people around me,
the first jump was more important than the second.

> I don't think we have /any/ gain in convenience labeling the current
> trunk 22.0 over 21.4.  And users expect major releases to be, well,
> major.  What reason does Emacs have to dis-regard that?

Please read my other messages.  If 21.4 turns out to be yet-another-bugfix,
we'll have to go through the code once again and fix various references
to it that assumed that it was going to be a major release.
I.e. the point is to choose the revision number long in advance and
independent from the number of other releases that will occur in-between.


	Stefan

Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
> > > > I don't have any strong feelings, but IMHO changing the major
> > > > version number after only 3 releases is generally undesirable.

> > > I don't see any good reason why this should be so.

> > I don't see any good reason why it shouldn't be so, and I don't
> > see any bad reason either.  Even if you don't think tradition,
> > conformance to the cultural expectations of Free Software users,
> > etc. are good reasons, you have to admit they're bad reasons :)

> What's the fundamental difference betweeen 3 or 4 revisions and 7
> (as in the Emacs-20 line) ?  Adding cua, tramp, ido, the elisp
> manual, calc, leim and more isn't enough to justify bumping the
> major revision counter ?  Why not ?

> > > What about between v17 and v18 ?

> > I don't think either of those existed.

> I actually don't know but I'd be surprised if you're right.  They
> might have never been released, but I expected they existed.

OK, let me expand on my comment: the major version number before 19
was (IIRC) 1: the version before v19 was 1.18.

> > > What about between v3 and v4 ?

> > I know those didn't exist.

> I again think you're wrong.

There was no GNU Emacs 3 or GNU Emacs 4.  There were 1.3 and 1.4, but
that was a minor change.

<snip>

> Yes, it has some importance.  It's important for people to know
> whether it's just a bugfix release or not.  But as for what defines
> a major change, as I said, this is very subjective.  In the past,
> Emacs revision numbers have been completely useless as "bugfix"
> indicators and have only been mildly useful as featureset
> predictors.  And I haven't heard many complaints about it, and the
> only complaints I heard were about distinguishing bugfix-releases,
> which my 2-part scheme handles just fine.

If we start making major releases on an annual basis, expect to start
hearing complaints :)

<snip>

> The only definition of "major" that I could find compelling

No comment on this

> and that seems to corresponds to past practices

So because past practice has been less than stellar at identifying
what should be a major release, we should drop the distinction?

> is "a major rework of the C code".  That does not necessarily have
> anything to do with what users perceive in term of features.  So if
> you consider major release numbers as indicators of "probably buggy
> because it has a lot of new code", I could agree.  But claiming that
> we should distinguish between the jump from 19.28->19.29 and
> 19.34->20.1 in terms of features is just not right, because to most
> people around me, the first jump was more important than the second.

What /was/ this crucial change from 19.28->19.29?  I'm curious now
(and given that there /was/ a 19.28, I'm wondering if there shouldn't
have been more major releases in there).

> > I don't think we have /any/ gain in convenience labeling the
> > current trunk 22.0 over 21.4.  And users expect major releases to
> > be, well, major.  What reason does Emacs have to dis-regard that?

> Please read my other messages.  If 21.4 turns out to be
> yet-another-bugfix, we'll have to go through the code once again and
> fix various references to it that assumed that it was going to be a
> major release.  I.e. the point is to choose the revision number long
> in advance and independent from the number of other releases that
> will occur in-between.

That's a one-time cost.  As I've pointed out, at some point my scheme
would take over and (nearly) /eliminate/ version number changes.  The
only change that would be possible is if we change a version from a
minor flip to a major flip, but that change would almost certainly
involve changing feature sets, too.  And then, :version tags will have
to roll anyway :)

> 	Stefan

Jon Cast

Re: No calc in pretest?

[Ken Raeburn]

Jon Cast <jcast@ou.edu> writes:
>>   Adding cua, tramp, ido, the elisp
>> manual, calc, leim and more isn't enough to justify bumping the
>> major revision counter ?  Why not ?

Recently the "major revisions" haven't been about new lisp packages,
but more fundamental changes to the core program, and even though I
don't make much use of it, I think that MULE support is a much more
significant change than adding any of these packages.


>> > > What about between v17 and v18 ?
>> > I don't think either of those existed.
>> I actually don't know but I'd be surprised if you're right.  They
>> might have never been released, but I expected they existed.
> OK, let me expand on my comment: the major version number before 19
> was (IIRC) 1: the version before v19 was 1.18.

Uh, no.  I just poked around at MIT and found a source tree for Emacs
18.59.  But I don't recall much about versions before 18.  X10 and VMS
support appear to be a couple of the big new features it added; remote
file access, pop-up menus and a bunch of other things were added too.
X11 support was added in 18.50.

Earlier versions are described in etc/ONEWS.* in the current tree.
Version 13 was preceded by 1.12.  The first change listed for v13 is:

    * There is a new version numbering scheme.

     What used to be the first version number, which was 1,
     has been discarded since it does not seem that I need three
     levels of version number.

     However, a new third version number has been added to represent
     changes by user sites.  This number will always be zero in
     Emacs when I distribute it; it will be incremented each time
     Emacs is built at another site.

There's also a reference to version "13.9".

Some other interesting tidbits:

Emacs 16 reduced redisplay during incremental searching on slow
terminals by displaying only a few lines.  I think I remember when
that change came along, so I'm pretty sure that at least the more
adventurous of us were using it in my group at MIT by then...

Emacs 15 added Sun 68k support, lisp stack overflow checks, texinfo.

Emacs 1.12 introduced support for "meta" characters.  Emacs 13
introduced the ?\M-x and ?\C-x syntax for using meta and control
characters in lisp.

Emacs 1.10 on VAX 4.2 BSD was 530K, after dumping.  Today it's what,
nearly 7M on x86?

Emacs 1.9 added support for "+" and "?" in regular expressions.

Emacs 1.7 changes say:

    It's Beat CCA Week.

CCA had a version of Emacs too.  It was a little more friendly in some
ways, perhaps, but had some serious problems, and GNU Emacs quickly
pulled ahead.  MIT's Project Athena (which provided some of the
software for students in the mid 80s) suffered with CCA Emacs for a
while -- at least, the less adventurous people did.


They're an interesting read.  Just in case anyone was thinking that
Emacs sprang fully-formed from RMS's forehead. :-)


> What trouble?  The trouble of converting to a three-element system
> (i.e., using fully general lexical ordering rather than un-rolling the
> loops), or the trouble of changing things if what we thought was x.y
> turns out to be (x+1).1?  Nobody's asking you to take any trouble
> about the first case, and I doubt the second case will be important
> enough to bother you.

Lexical ordering doesn't work on this style of version number.  By
general lexical ordering, 22.10.1 comes before 22.9.1, because "1"
comes before "9".  And the immediate successor to "22.9" is "22.:" if
you go by the ASCII chart. :-)

It's multiple numbers, each possibly with multiple digits, separated
by dots; that's how it has to be sorted.

If we want lexical sorting to work, we could require two- or
three-digit fields with leading zeros, and no overflow allowed --
i.e., no ".100" after ".99" even if more pretests are needed, but
".100" after ".099" would be okay.


My two cents on the issue:

I like the "major.minor.bugfix[.yyyymmdd]" proposal.

"Real" releases with new development work and bugfix releases can be
distinguished at a glance, and for the most part we can predict what
the next version of each type would be called.  We don't have to tell
people, "I just put this change in on the trunk, it'll be in release
21 point ... uh ... lemme think, 'nother bugfix release is in the
works, that'll be 21.17, so the next release off the trunk is 21.18.
Yeah, it'll be in 21.18.  Or not, if things change."  With the extra
field for bugfixes, we can say "21.18" and mean it -- unless there's
no new release before version 22, but someone who was told something
would be in 21.18 will probably figure it out easily.

Leaving off the bugfix number for the initial release (i.e., "21.4" to
be followed by "21.4.1" with bugfixes) leads to confusions when the
build process tacks on another number indicating the local build
count.  So, third build of 21.4 would be 21.4.3, but the first build
of the bugfix release following it would be 21.4.1.1; no, that's no
good.  And the datestamp would just magnify that problem.  But
datestamps are much larger than any local build count is going to be,
so the version ordering is still clear when datestamps are added (if
you do your sorting correctly).

Starting at .1 instead of .0 makes sense, so that each prerelease can
have the .90 or whatever and still use the new version at the higher
level, i.e., 22.0.90 is clearly in the v22 line *and* comes before
22.1, the first real release in that line.

Ken

Re: No calc in pretest?

[Jon Cast]

Ken Raeburn <raeburn@raeburn.org> wrote:
<snip, including some fascinating Emacs history>

Btw., thanks for all this.  I apologize for saying 18 was the first
non-1.x release (whoops), but I stand firm in my position major number
changes have always meant significant changes internally (although
clearly not the other way around).  So, we should /not/ use x.0 to
indicate `release from CVS head'.

> > What trouble?  The trouble of converting to a three-element system
> > (i.e., using fully general lexical ordering rather than un-rolling
> > the loops), or the trouble of changing things if what we thought
> > was x.y turns out to be (x+1).1?  Nobody's asking you to take any
> > trouble about the first case, and I doubt the second case will be
> > important enough to bother you.

> Lexical ordering doesn't work on this style of version number.  By
> general lexical ordering, 22.10.1 comes before 22.9.1, because "1"
> comes before "9".  And the immediate successor to "22.9" is "22.:"
> if you go by the ASCII chart. :-)

Sorry, I meant lexical ordering in the mathematical sense: i.e., parse
21.4.0.50.yyyymmdd.z as (21 4 0 50 yyyymmdd) and then define ordering
as

(defun lte (xn ys)
       (or (= xn nil)
           (and (listp xn) (listp ys)
                (or (< (car xn) (car ys))
                    (and (= (car xn) (car ys))
                         (lte (cdr xn) (cdr ys)))))))

(I think; my lisp is a little weak.)

> It's multiple numbers, each possibly with multiple digits, separated
> by dots; that's how it has to be sorted.

Right.

> If we want lexical sorting to work, we could require two- or
> three-digit fields with leading zeros, and no overflow allowed --
> i.e., no ".100" after ".99" even if more pretests are needed, but
> ".100" after ".099" would be okay.

We could, but I'd rather not.

> My two cents on the issue:

> I like the "major.minor.bugfix[.yyyymmdd]" proposal.

> "Real" releases with new development work and bugfix releases can be
> distinguished at a glance, and for the most part we can predict what
> the next version of each type would be called.  We don't have to
> tell people, "I just put this change in on the trunk, it'll be in
> release 21 point ... uh ... lemme think, 'nother bugfix release is
> in the works, that'll be 21.17, so the next release off the trunk is
> 21.18.  Yeah, it'll be in 21.18.  Or not, if things change."  With
> the extra field for bugfixes, we can say "21.18" and mean it --
> unless there's no new release before version 22, but someone who was
> told something would be in 21.18 will probably figure it out easily.

> Leaving off the bugfix number for the initial release (i.e., "21.4"
> to be followed by "21.4.1" with bugfixes) leads to confusions when
> the build process tacks on another number indicating the local build
> count.  So, third build of 21.4 would be 21.4.3, but the first build
> of the bugfix release following it would be 21.4.1.1; no, that's no
> good.  And the datestamp would just magnify that problem.  But
> datestamps are much larger than any local build count is going to
> be, so the version ordering is still clear when datestamps are added
> (if you do your sorting correctly).

> Starting at .1 instead of .0 makes sense, so that each prerelease
> can have the .90 or whatever and still use the new version at the
> higher level, i.e., 22.0.90 is clearly in the v22 line *and* comes
> before 22.1, the first real release in that line.

I agree; it also means loadup.el won't cause any confusion by
declaring 22 22.1 and 22.1 22.1.1 :)

> Ken

Jon Cast

Re: No calc in pretest?

[Miles Bader]

Jon Cast <jcast@ou.edu> writes:
> I apologize for saying 18 was the first non-1.x release (whoops), but
> I stand firm in my position major number changes have always meant
> significant changes internally (although clearly not the other way
> around).

Anyway I don't think it really matters if this convention wasn't
followed strictly a long time ago; it's been followed pretty
consistently for over a decade at least, I'd say, and people definitely
get excited when they hear that an emacs release with a bumped major
version is coming...

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: No calc in pretest?

[Jon Cast]

Miles Bader <miles@lsi.nec.co.jp> wrote:
> Anyway I don't think it really matters if this convention wasn't
> followed strictly a long time ago; it's been followed pretty
> consistently for over a decade at least, I'd say, and people
> definitely get excited when they hear that an emacs release with a
> bumped major version is coming...

Exactly.

> -Miles

Jon Cast

Re: No calc in pretest?

[Kai Großjohann]

Jon Cast <jcast@ou.edu> writes:

> What /was/ this crucial change from 19.28->19.29?  I'm curious now
> (and given that there /was/ a 19.28, I'm wondering if there shouldn't
> have been more major releases in there).

The maximum buffer size increased from 8M to 128M (on 32 bit
architectures).

There was also a time in the 19 series where the Lucid toolkit was
added, but I don't quite remember when.  Could be 19.19 or 19.25 when
it was added; I remember these versions as yard-rocks (is that
between inch-pebbles and mile-stones?).

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: No calc in pretest?

[Jon Cast]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> Jon Cast <jcast@ou.edu> writes:

> > What /was/ this crucial change from 19.28->19.29?  I'm curious now
> > (and given that there /was/ a 19.28, I'm wondering if there
> > shouldn't have been more major releases in there).

> The maximum buffer size increased from 8M to 128M (on 32 bit
> architectures).

I see.  You could argue that should have been a major version change,
then.  But I still don't think saying the next version should be 22.0
follows from that :)

> There was also a time in the 19 series where the Lucid toolkit was
> added, but I don't quite remember when.  Could be 19.19 or 19.25
> when it was added; I remember these versions as yard-rocks (is that
> between inch-pebbles and mile-stones?).

See above

> kai
> --
> A large number of young women don't trust men with beards.  (BFBS Radio)

Jon Cast

p.s.: Kai: I hope I got your name right above; I'm sorry if I made a
mistake.

Re: No calc in pretest?

[Robert J. Chassell]

    What about between v17 and v18 ?

You could run Version 18 Emacs in VMS.  This was a big deal.

Also, searching was made several times faster, and Emacs could no
longer run out of memeory during garbage collection.  These, too, were
big deals.

In general major version number changes have always been big deals.

The change that seems to have caused all this discussion is the idea
of having two tracks, a `bug-fix' track, and a `new-features' track.
In the past, there was only one track, which included both bug fixes
and new features.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: No calc in pretest?

[Jon Cast]

Robert J. Chassell" <bob@rattlesnake.com> wrote:
<snip>
> The change that seems to have caused all this discussion is the idea
> of having two tracks, a `bug-fix' track, and a `new-features' track.
> In the past, there was only one track, which included both bug fixes
> and new features.

There /are/ two tracks already.  The problem is, they're interleaved,
so you can't tell which track a particular release is on.  The
discussion is simply looking for a way to dis-entangle the tracks.

> --
>     Robert J. Chassell                  bob@rattlesnake.com
>     Rattlesnake Enterprises             http://www.rattlesnake.com

Jon Cast

Re: No calc in pretest?

[Richard Stallman]

       v19 - support for X
       v20 - m17n
       v21 - new display engine

    If we follow this, v22 should be the Unicode-based Emacs, not some 
    intermediate release.

I agree.

Re: No calc in pretest?

[Jon Cast]

storm@cua.dk (Kim F. Storm) wrote:
> Alternatively, we could adapt the linux numbering where odd-minor
> are development versions and even-minor are releases, e.g.

>         22.1.1  -- CVS development version for 22.2
>         22.1.90 -- pretest for 22.2

>         22.2.1 -- initial release
>         22.2.2 -- bug-fix

>         22.3.1 -- CVS development version for 22.4
>         22.3.90 -- pretest

>         22.4.1 -- release

I don't think this is necessary, and it might be too similar to Linux
to avoid confusing people---the second number in a Linux version
number is practically a major version number; we don't want to give
the impression that's true for Emacs.

<snip>

> The suggested numbering scheme would also allow us to make
> development snapshots like 22.1.1, 22.1.2, 22.1.3 etc. to be
> announced on the pretesters list for interrim feedback during
> development for those interested.  [I'm not implying that we
> _should_ do this, just that we _can_ do it].

We could also call the development snapshots 21.4.50, 21.4.51, etc.
Even better would be 21.4.50.yyyymmdd, IMO (also, yyyymmdd makes it
abundantly clear it's a snapshot, even to people who don't understand
the Linux numbering scheme.)

> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

Jon Cast

Re: No calc in pretest?

[Kim F. Storm]

Jon Cast <jcast@ou.edu> writes:

> 
> We could also call the development snapshots 21.4.50, 21.4.51, etc.
> Even better would be 21.4.50.yyyymmdd, IMO (also, yyyymmdd makes it
> abundantly clear it's a snapshot, even to people who don't understand
> the Linux numbering scheme.)

I like this idea!

But I think we should number snapshots -- including pretests -- as

        21.5.0.yyyymmdd

Then the major and minor number for the pretest and snapshots
would be the same as for the actual release.

The current scheme suffers from the problem that the minor
number is off by one...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Jon Cast]

storm@cua.dk (Kim F. Storm) wrote:
> Jon Cast <jcast@ou.edu> writes:
> > We could also call the development snapshots 21.4.50, 21.4.51,
> > etc.  Even better would be 21.4.50.yyyymmdd, IMO (also, yyyymmdd
> > makes it abundantly clear it's a snapshot, even to people who
> > don't understand the Linux numbering scheme.)

> I like this idea!

> But I think we should number snapshots -- including pretests -- as

>         21.5.0.yyyymmdd

> Then the major and minor number for the pretest and snapshots
> would be the same as for the actual release.

> The current scheme suffers from the problem that the minor
> number is off by one...

Again, I'm a strong believer in lexicographic ordering.
21.5.0.yyyymmdd sorts higher than 21.5.0, so it should be a later
release.

> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Kim F. Storm]

Jon Cast <jcast@ou.edu> writes:

> 
> Again, I'm a strong believer in lexicographic ordering.

IMO, it doesn't really matter as long as our primary focus is using
consistent values for emacs-major-version (21) and emacs-minor-version
(5).

> 21.5.0.yyyymmdd sorts higher than 21.5.0, so it should be a later
> release.

Then call the initial release 21.5.1.


In my company, we (the R&D people) have implemented the version number
as a free-format string.  The actual contents of this string for any
given release is defined by Marketing (implying that it doesn't have
to make sense [to us] :-)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Jon Cast]

storm@cua.dk (Kim F. Storm) wrote:
> Jon Cast <jcast@ou.edu> writes:
<snip>
> > 21.5.0.yyyymmdd sorts higher than 21.5.0, so it should be a later
> > release.

> Then call the initial release 21.5.1.

You mean like this?

21.5.0.50.yyyymmdd -- CVS leading up to 21.5.1
21.5.0.9x.         -- Pre-test for 21.5.1
21.5.1             -- Release from CVS head
21.5.x             -- Bug-fix release (x > 1)

I *think* that should satisfy both of us.  I'm happy with it; how
about you?

The reason for having separate version numbers for CVS
(x.y.0.50.yyyymmdd and x.y.0.9z) is that I think emacsbug.el needs to
be able to differentiate them, and that seems easiest to implement
(not to mention most similar to other GNU programs).  I'm not really
attached to it outside of those two reasons, and I'm not at all
attached to x.y.0.9z vs. x.y.0.90.yyyymmdd.  The date just seems less
necessary for pre-tests, since they change less often.  The visual
tagging it provides could justify it, though.

<snip>

> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

Jon Cast

Re: No calc in pretest?

[Kim F. Storm]

Jon Cast <jcast@ou.edu> writes:

> storm@cua.dk (Kim F. Storm) wrote:
> > Jon Cast <jcast@ou.edu> writes:
> <snip>
> > > 21.5.0.yyyymmdd sorts higher than 21.5.0, so it should be a later
> > > release.
> 
> > Then call the initial release 21.5.1.
> 
> You mean like this?
> 
> 21.5.0.50.yyyymmdd -- CVS leading up to 21.5.1
> 21.5.0.9x.         -- Pre-test for 21.5.1
> 21.5.1             -- Release from CVS head
> 21.5.x             -- Bug-fix release (x > 1)
> 
> I *think* that should satisfy both of us.  I'm happy with it; how
> about you?

Hm.

I don't see any reason to separate CVS snapshot versions from pretest
versions.  emacsbug.el should (probably) send bug reports for either
type of build to the emacs-pretest-bug address.

So I suggest the following:

21.5.0.0          -- Direct build from CVS head.
21.5.0.yyyymmdd   -- Snapshot or pretest from CVS head.
21.5.1            -- Initial release from CVS head.
21.5.x            -- Bug-fix release (x > 1)


The build number is appended to these numbers, so we end up with
the users seeing numbers like this where y is typically 1.

21.5.0.0.y
21.5.0.20020703.y
21.5.1.y
21.5.x.y

For the release build numbers, this looks ok.

For the CVS builds, this is also ok, as it clearly differentiates
these builds from builds based on official releases.

> 
> The reason for having separate version numbers for CVS
> (x.y.0.50.yyyymmdd and x.y.0.9z) is that I think emacsbug.el needs to
> be able to differentiate them, and that seems easiest to implement

No, emacsbug counts the number of `.'s in the version string,
and if there is more than 2 (currently), it supposes it is
a pretest.

With my scheme, the test would simply be 
        (let ((pretest-p (= emacs-minor-minor-version 0)))
        ...)


of course, I'm assuming we have a variable containing the minor-minor
number (can someone come up with a better term?)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: No calc in pretest?

[Jon Cast]

storm@cua.dk (Kim F. Storm) wrote:
<snip>
> I don't see any reason to separate CVS snapshot versions from
> pretest versions.  emacsbug.el should (probably) send bug reports
> for either type of build to the emacs-pretest-bug address.

I take it by ``snapshot'' you mean a tarball containing the state of
CVS on a particular date, right?

> So I suggest the following:

> 21.5.0.0          -- Direct build from CVS head.
> 21.5.0.yyyymmdd   -- Snapshot or pretest from CVS head.
> 21.5.1            -- Initial release from CVS head.
> 21.5.x            -- Bug-fix release (x > 1)

Why differentiate CVS from snapshots?  I'd assume the current date
could be written into CVS by a cron script on subversions or
elsewhere, and that would also keep the ordering correct---with your
scheme, my CVS checkout made today (version 21.5.0.0) looks older than
the next guys CVS snapshot release three weeks ago (version
21.5.0.20020803).  That's not good.  It's not catastrophic, but it's
not good.

> The build number is appended to these numbers, so we end up with the
> users seeing numbers like this where y is typically 1.

> 21.5.0.0.y
> 21.5.0.20020703.y
> 21.5.1.y
> 21.5.x.y

> For the release build numbers, this looks ok.

> For the CVS builds, this is also ok, as it clearly differentiates
> these builds from builds based on official releases.

I agree this looks good.  I'm not convinced CVS bugs go to the
emacs-pretest-bug address, but I think the resulting schemes are
sufficiently similar we can go with your scheme unless we get a more
definitive answer.

> > The reason for having separate version numbers for CVS
> > (x.y.0.50.yyyymmdd and x.y.0.9z) is that I think emacsbug.el needs
> > to be able to differentiate them, and that seems easiest to
> > implement

> No, emacsbug counts the number of `.'s in the version string, and if
> there is more than 2 (currently), it supposes it is a pretest.

I know what emacsbug does.  What I meant was, checking a particular
number seems easiest to implement, and (nth 4 (parse-version
emacs-version)) (where `parse-version' returns a list of the
components of its argument) seemed as good a number as any.

> With my scheme, the test would simply be
>         (let ((pretest-p (= emacs-minor-minor-version 0)))
>         ...)

What about bug-fix pretests?  Those probably shouldn't have
emacs-micro-version = 0 --- that destroys the lexical ordering on
versions again.  (Please don't tell me you'd object to calling
21.5.(x+1)'s pretest 21.5.x.90 --- micro numbers have infinitesimal
information for programs anyway.)

> of course, I'm assuming we have a variable containing the
> minor-minor number (can someone come up with a better term?)

Micro number sounds good to me.

> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

crash in display, triggered by calendar

[Sam Steingold]

GNU Emacs 21.3.50.22 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-08-06 on glip.premonitia.com

in the CVS head emacs, build a minute ago:

emacs has a long-standing bug: diary requires that diary-file 
(normally "~/.diary") to be writable or to start with a newline.
Now this old bug triggers a crash.

$ cd ~
$ mv .diary .diary.tmp
$ echo ';' > .diary
$ cat .diary.tmp >> .diary
$ rm -f .diary.tmp
$ chmod -w .diary
$ emacs
M-x calendar
M-x view-diary-entries

you will get a message in the minibuffer that #<buffer .diary> is
read-only (even if you set debug-on-error to t, you will not get a
backtrace!)

C-x b .diary RET

===> CRASH!!!


Program received signal SIGSEGV, Segmentation fault.
next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4819
4819      int success_p = 1;
(gdb) where
#0  next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4819
#1  0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#2  0x0806053f in forward_to_next_line_start (it=0xbfffe3f0, 
    skipped_p=0xbf8000a8) at xdisp.c:3871
#3  0x08060781 in reseat_at_next_visible_line_start (it=0xbfffe3f0, 
    on_newline_p=1) at xdisp.c:3996
#4  0x0806165b in next_element_from_ellipsis (it=0xbfffe3f0) at xdisp.c:4775
#5  0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#6  0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#7  0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#8  0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#9  0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#10 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#11 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#12 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#13 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#14 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#15 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#16 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#17 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#18 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#19 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#20 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#21 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#22 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#23 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#24 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#25 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#26 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#27 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#28 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#29 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#30 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#31 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#32 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#33 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#34 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#35 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#36 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#37 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#38 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#39 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#40 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#41 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#42 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#43 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#44 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#45 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#46 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#47 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#48 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#49 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#50 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#51 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#52 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#53 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#54 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#55 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#56 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
---Type <return> to continue, or q <return> to quit---
#57 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#58 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#59 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#60 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#61 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#62 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#63 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#64 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#65 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#66 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#67 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#68 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#69 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#70 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#71 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#72 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#73 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#74 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#75 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#76 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#77 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#78 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#79 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#80 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#81 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#82 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#83 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#84 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#85 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#86 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#87 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#88 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#89 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#90 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#91 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#92 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#93 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#94 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#95 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#96 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#97 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#98 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#99 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#100 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#101 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#102 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#103 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#104 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#105 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#106 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#107 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#108 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#109 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#110 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#111 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#112 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#113 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
#114 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
#115 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) p it
$3 = (struct it *) 0xbfffe3f0
(gdb) p *it
$4 = {
  window = 1212942904, 
  w = 0x84c0a38, 
  f = 0x84c0910, 
  method = 0x80616a4 <next_element_from_buffer>, 
  stop_charpos = 5866, 
  end_charpos = 5866, 
  s = 0x0, 
  string_nchars = 0, 
  region_beg_charpos = -1, 
  region_end_charpos = -1, 
  redisplay_end_trigger_charpos = 0, 
  multibyte_p = 1, 
  header_line_p = 0, 
  string_from_display_prop_p = 0, 
  dp = 0x82d3f88, 
  dpvec = 0x0, 
  dpend = 0xbfffe43c, 
  dpvec_char_len = 1, 
  saved_face_id = 0, 
  ctl_chars = {94, 77, 0 <repeats 14 times>}, 
  current = {
    pos = {
      charpos = 5865, 
      bytepos = 5865
    }, 
    overlay_string_index = -1, 
    string_pos = {
      charpos = -1, 
      bytepos = -1
    }, 
    dpvec_index = -1
  }, 
  overlay_strings = {0, 0, 0}, 
  n_overlay_strings = 0, 
  string = 405361476, 
  stack = {{
      stop_charpos = 0, 
      face_id = 0, 
      string = 0, 
      pos = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      end_charpos = 0, 
      string_nchars = 0, 
      area = LEFT_MARGIN_AREA, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
---Type <return> to continue, or q <return> to quit---
      voffset = 0, 
      font_height = 0
    }, {
      stop_charpos = 0, 
      face_id = 0, 
      string = 0, 
      pos = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      end_charpos = 0, 
      string_nchars = 0, 
      area = LEFT_MARGIN_AREA, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
      voffset = 0, 
      font_height = 0
    }}, 
  sp = 0, 
  selective_display_ellipsis_p = 0, 
  ctl_arrow_p = 1, 
  selective = 0, 
  what = IT_CHARACTER, 
  face_id = 0, 
  face_box_p = 0, 
  start_of_box_run_p = 0, 
  end_of_box_run_p = 0, 
  overlay_strings_at_end_processed_p = 1, 
  glyph_not_available_p = 0, 
  starts_in_middle_of_char_p = 0, 
  face_before_selective_p = 1, 
  base_face_id = 0, 
  c = 13, 
  len = 1, 
  cmp_id = 0, 
  cmp_len = 0, 
  char_to_display = 33, 
  image_id = 0, 
  space_width = 405361476, 
  voffset = 0, 
  font_height = 405361476, 
  object = 1215887680, 
  position = {
    charpos = 5865, 
    bytepos = 5865
  }, 
  truncate_lines_p = 0, 
  tab_width = 8, 
  truncation_pixel_width = 0, 
---Type <return> to continue, or q <return> to quit---
  continuation_pixel_width = 0, 
  first_visible_x = 0, 
  last_visible_x = 480, 
  last_visible_y = 725, 
  extra_line_spacing = 0, 
  glyph_row = 0x84d149c, 
  area = TEXT_AREA, 
  nglyphs = 1, 
  pixel_width = 6, 
  ascent = 11, 
  descent = 2, 
  max_ascent = 11, 
  max_descent = 2, 
  phys_ascent = 9, 
  phys_descent = 0, 
  max_phys_ascent = 11, 
  max_phys_descent = 2, 
  current_x = 402, 
  continuation_lines_width = 0, 
  current_y = 91, 
  vpos = 7, 
  hpos = 59
}



 

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Are you smart enough to use Lisp?

Re: crash in display, triggered by calendar

[Ed Reingold]

Does the error below (the crash) occur in earlier releases--version 20, say?  
It hasn't happened to me.

The diary processing code does NOT require that diary-file be writable or start
with a newline.  At least it is not supposed to.  However, if the file does not
begin and end with newlines they MUST be added or the simple diary display
mechanism (selective display) cannot work; but this is done in a protected way,
however (at least I thought it was).

Since I still use version 20, I will need help in figuring out the error.

By the way, if I had my druthers, there would be no simple diary display, only 
the fancy one, and the problem would not exist.  The simple display is and has 
always been a problem; I added it at RMS's insistence.

> GNU Emacs 21.3.50.22 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2002-08-06 on glip.premonitia.com
> 
> in the CVS head emacs, build a minute ago:
> 
> emacs has a long-standing bug: diary requires that diary-file 
> (normally "~/.diary") to be writable or to start with a newline

> Now this old bug triggers a crash.
> 
> $ cd ~
> $ mv .diary .diary.tmp
> $ echo ';' > .diary
> $ cat .diary.tmp >> .diary
> $ rm -f .diary.tmp
> $ chmod -w .diary
> $ emacs
> M-x calendar
> M-x view-diary-entries
> 
> you will get a message in the minibuffer that #<buffer .diary> is
> read-only (even if you set debug-on-error to t, you will not get a
> backtrace!)
> 
> C-x b .diary RET
> 
> ===> CRASH!!!
> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4819
> 4819      int success_p = 1;
> (gdb) where
> #0  next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4819
> #1  0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #2  0x0806053f in forward_to_next_line_start (it=0xbfffe3f0, 
>     skipped_p=0xbf8000a8) at xdisp.c:3871
> #3  0x08060781 in reseat_at_next_visible_line_start (it=0xbfffe3f0, 
>     on_newline_p=1) at xdisp.c:3996
> #4  0x0806165b in next_element_from_ellipsis (it=0xbfffe3f0) at xdisp.c:4775
> #5  0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #6  0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #7  0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #8  0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #9  0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #10 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #11 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #12 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #13 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #14 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #15 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #16 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #17 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #18 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #19 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #20 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #21 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #22 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #23 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #24 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #25 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #26 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #27 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #28 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #29 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #30 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #31 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #32 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #33 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #34 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #35 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #36 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #37 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #38 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #39 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #40 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #41 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #42 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #43 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #44 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #45 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #46 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #47 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #48 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #49 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #50 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #51 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #52 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #53 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #54 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #55 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #56 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> ---Type <return> to continue, or q <return> to quit---
> #57 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #58 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #59 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #60 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #61 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #62 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #63 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #64 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #65 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #66 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #67 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #68 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #69 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #70 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #71 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #72 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #73 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #74 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #75 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #76 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #77 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #78 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #79 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #80 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #81 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #82 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #83 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #84 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #85 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #86 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #87 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #88 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #89 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #90 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #91 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #92 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #93 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #94 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #95 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #96 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #97 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #98 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #99 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #100 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #101 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #102 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #103 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #104 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #105 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #106 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #107 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #108 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #109 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #110 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #111 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #112 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #113 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> #114 0x08060b88 in get_next_display_element (it=0xbfffe3f0) at xdisp.c:4213
> #115 0x080618eb in next_element_from_buffer (it=0xbfffe3f0) at xdisp.c:4909
> ---Type <return> to continue, or q <return> to quit---q
> Quit
> (gdb) p it
> $3 = (struct it *) 0xbfffe3f0
> (gdb) p *it
> $4 = {
>   window = 1212942904, 
>   w = 0x84c0a38, 
>   f = 0x84c0910, 
>   method = 0x80616a4 <next_element_from_buffer>, 
>   stop_charpos = 5866, 
>   end_charpos = 5866, 
>   s = 0x0, 
>   string_nchars = 0, 
>   region_beg_charpos = -1, 
>   region_end_charpos = -1, 
>   redisplay_end_trigger_charpos = 0, 
>   multibyte_p = 1, 
>   header_line_p = 0, 
>   string_from_display_prop_p = 0, 
>   dp = 0x82d3f88, 
>   dpvec = 0x0, 
>   dpend = 0xbfffe43c, 
>   dpvec_char_len = 1, 
>   saved_face_id = 0, 
>   ctl_chars = {94, 77, 0 <repeats 14 times>}, 
>   current = {
>     pos = {
>       charpos = 5865, 
>       bytepos = 5865
>     }, 
>     overlay_string_index = -1, 
>     string_pos = {
>       charpos = -1, 
>       bytepos = -1
>     }, 
>     dpvec_index = -1
>   }, 
>   overlay_strings = {0, 0, 0}, 
>   n_overlay_strings = 0, 
>   string = 405361476, 
>   stack = {{
>       stop_charpos = 0, 
>       face_id = 0, 
>       string = 0, 
>       pos = {
>         pos = {
>           charpos = 0, 
>           bytepos = 0
>         }, 
>         overlay_string_index = 0, 
>         string_pos = {
>           charpos = 0, 
>           bytepos = 0
>         }, 
>         dpvec_index = 0
>       }, 
>       end_charpos = 0, 
>       string_nchars = 0, 
>       area = LEFT_MARGIN_AREA, 
>       multibyte_p = 0, 
>       string_from_display_prop_p = 0, 
>       display_ellipsis_p = 0, 
>       space_width = 0, 
> ---Type <return> to continue, or q <return> to quit---
>       voffset = 0, 
>       font_height = 0
>     }, {
>       stop_charpos = 0, 
>       face_id = 0, 
>       string = 0, 
>       pos = {
>         pos = {
>           charpos = 0, 
>           bytepos = 0
>         }, 
>         overlay_string_index = 0, 
>         string_pos = {
>           charpos = 0, 
>           bytepos = 0
>         }, 
>         dpvec_index = 0
>       }, 
>       end_charpos = 0, 
>       string_nchars = 0, 
>       area = LEFT_MARGIN_AREA, 
>       multibyte_p = 0, 
>       string_from_display_prop_p = 0, 
>       display_ellipsis_p = 0, 
>       space_width = 0, 
>       voffset = 0, 
>       font_height = 0
>     }}, 
>   sp = 0, 
>   selective_display_ellipsis_p = 0, 
>   ctl_arrow_p = 1, 
>   selective = 0, 
>   what = IT_CHARACTER, 
>   face_id = 0, 
>   face_box_p = 0, 
>   start_of_box_run_p = 0, 
>   end_of_box_run_p = 0, 
>   overlay_strings_at_end_processed_p = 1, 
>   glyph_not_available_p = 0, 
>   starts_in_middle_of_char_p = 0, 
>   face_before_selective_p = 1, 
>   base_face_id = 0, 
>   c = 13, 
>   len = 1, 
>   cmp_id = 0, 
>   cmp_len = 0, 
>   char_to_display = 33, 
>   image_id = 0, 
>   space_width = 405361476, 
>   voffset = 0, 
>   font_height = 405361476, 
>   object = 1215887680, 
>   position = {
>     charpos = 5865, 
>     bytepos = 5865
>   }, 
>   truncate_lines_p = 0, 
>   tab_width = 8, 
>   truncation_pixel_width = 0, 
> ---Type <return> to continue, or q <return> to quit---
>   continuation_pixel_width = 0, 
>   first_visible_x = 0, 
>   last_visible_x = 480, 
>   last_visible_y = 725, 
>   extra_line_spacing = 0, 
>   glyph_row = 0x84d149c, 
>   area = TEXT_AREA, 
>   nglyphs = 1, 
>   pixel_width = 6, 
>   ascent = 11, 
>   descent = 2, 
>   max_ascent = 11, 
>   max_descent = 2, 
>   phys_ascent = 9, 
>   phys_descent = 0, 
>   max_phys_ascent = 11, 
>   max_phys_descent = 2, 
>   current_x = 402, 
>   continuation_lines_width = 0, 
>   current_y = 91, 
>   vpos = 7, 
>   hpos = 59
> }
> 
> 
> 
>  
> 
> -- 
> Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
> <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
> Are you smart enough to use Lisp?
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: crash in display, triggered by calendar

[Sam Steingold]

> * In message <200208061338.g76DcRY20077@emr.cs.iit.edu>
> * On the subject of "Re: crash in display, triggered by calendar "
> * Sent on Tue, 06 Aug 2002 08:38:27 -0500
> * Honorable Ed Reingold <reingold@emr.cs.iit.edu> writes:
>
> The diary processing code does NOT require that diary-file be writable
> or start with a newline.  At least it is not supposed to.  However, if
> the file does not begin and end with newlines they MUST be added or
> the simple diary display mechanism (selective display) cannot work;
> but this is done in a protected way, however (at least I thought it
> was).

diary always leaves ~/.diary with the leading newline that it adds, and
it has always done it.

> By the way, if I had my druthers, there would be no simple diary
> display, only the fancy one, and the problem would not exist.  The
> simple display is and has always been a problem; I added it at RMS's
> insistence.

I suggest that you remove it.
RMS reads this list - I hope he will withdraw his insistence.

At any rate, these are two separate issues: the redisplay crash and the
newline in diary.

PS. may I suggest that you add some defvars in diary-lib.el to avoid
compiler warnings?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
God had a deadline, so He wrote it all in Lisp.

Re: crash in display, triggered by calendar

[Alan Shutko]

Sam Steingold <sds@gnu.org> writes:

> diary always leaves ~/.diary with the leading newline that it adds, and
> it has always done it.

Right, although it only matters if you later edit and save the
buffer.  It adds the newline without marking the buffer as
modified... though I don't know what it does if the buffer's read
only.  Seems to complain.  That should be fixable.

I can replicate the crash, so I'll see if I can figure out why it's
happening.

> PS. may I suggest that you add some defvars in diary-lib.el to avoid
> compiler warnings?

Hmmm... I'm not sure a good idea in all the cases.  Some of the
variables (diary-entries-list, or entry in sexp forms) never exist at
the top level.  Ed, what do you think?

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
We sought the truth where it was least obvious.

Re: crash in display, triggered by calendar

[Ed Reingold]

> Sam Steingold <sds@gnu.org> writes:
> 
> > diary always leaves ~/.diary with the leading newline that it adds, and
> > it has always done it.
> 
> Right, although it only matters if you later edit and save the
> buffer.  It adds the newline without marking the buffer as
> modified... though I don't know what it does if the buffer's read
> only.  Seems to complain.  That should be fixable.

I thought I protected it when the buffer was read only.  What did I miss?

> I can replicate the crash, so I'll see if I can figure out why it's
> happening.

That would be great!

> > PS. may I suggest that you add some defvars in diary-lib.el to avoid
> > compiler warnings?
> 
> Hmmm... I'm not sure a good idea in all the cases.  Some of the
> variables (diary-entries-list, or entry in sexp forms) never exist at
> the top level.  Ed, what do you think?

I have always thought that warnings are just that: warnings to be careful, NOT
bugs.  In this case, the warnings are meaningless, so I think the defvars are
meaningless too.  I don't object if somebody adds them, but I wouldn't bother.

Re: crash in display, triggered by calendar

[Sam Steingold]

> * In message <200208061451.g76EphY20584@emr.cs.iit.edu>
> * On the subject of "Re: crash in display, triggered by calendar "
> * Sent on Tue, 06 Aug 2002 09:51:42 -0500
> * Honorable Ed Reingold <reingold@emr.cs.iit.edu> writes:
>
> > > PS. may I suggest that you add some defvars in diary-lib.el to avoid
> > > compiler warnings?
> > 
> > Hmmm... I'm not sure a good idea in all the cases.  Some of the
> > variables (diary-entries-list, or entry in sexp forms) never exist at
> > the top level.  Ed, what do you think?
> 
> I have always thought that warnings are just that: warnings to be
> careful, NOT bugs.  In this case, the warnings are meaningless, so I
> think the defvars are meaningless too.  I don't object if somebody
> adds them, but I wouldn't bother.

When you get a zillion of warnings you are used to ignore, you will
miss an important one.
I suggest top-level defvar's without binding the variables.
This way you are clearly declaring that you are using these as global
specials.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
War doesn't determine who's right, just who's left.

Re: crash in display, triggered by calendar

[Richard Stallman]

    > PS. may I suggest that you add some defvars in diary-lib.el to avoid
    > compiler warnings?

    Hmmm... I'm not sure a good idea in all the cases.  Some of the
    variables (diary-entries-list, or entry in sexp forms) never exist at
    the top level.  Ed, what do you think?

What does "exist at top level" mean for a variable?  Do you mean
that they don't have any global bindings?

It is ok to defvar variables that don't have global bindings.

It is also ok to write a defvar that gives them global bindings of
nil; If those global bindings are never used, they don't do any harm.
This way, the defvar can have a doc string.  Those doc strings will be
useful.

The one somewhat ugly aspect is that some of these variables, such as
number, date, entry, and d-file, have very short and nondescript names
not tied to the diary package.  It is somewhat unclean to be using
those names in this way.

What are those variables used for?  Can we rename them?
Can we rename displayed-month to diary-month, etc?
Aside from date, none of them seems to be documented
in either manual.

Re: crash in display, triggered by calendar

[Richard Stallman]

    I suggest that you remove it.
    RMS reads this list - I hope he will withdraw his insistence.

Nope.

invalid-regexp in calendar

[Sam Steingold]

GNU Emacs 21.3.50.1 (i386-msvc-nt5.0.2195)
 of 2004-01-08 on WINSTEINGOLDLAP
--with-msvc (12.00)

Debugger entered--Lisp error: (invalid-regexp "Unmatched ) or \\)")
  string-match("\\`[ 	\n\\^M]*\\([0-9]?[0-9]\\)[:.][\\([0-9][0-9]\\)\\([ap]\\)m\\>" "Day 22 of 2004; 344 days remaining in the year")
  diary-entry-time("Day 22 of 2004; 344 days remaining in the year")
  diary-entry-compare(((1 22 2004) "Day 22 of 2004; 344 days remaining in the year" "&%%(diary-day-of-year)" #<marker at 2188 in .diary> nil) ((1 22 2004) "Daylight [Eastern Standard Time]: 07:08/16:44 [=9:35] at Boston, MA, USA" "&%%(diary-sunrise-sunset)" #<marker at 1952 in .diary> nil))
  sort((((1 22 2004) "Hebrew date (until sunset): 5764, Teveth 28" "&%%(diary-hebrew-date)" #<marker at 1929 in .diary> nil)) diary-entry-compare)
  sort-diary-entries()
  run-hooks(nongregorian-diary-listing-hook list-diary-entries-hook)
  list-diary-entries((1 22 2004) 1)
  view-diary-entries(1)
* call-interactively(view-diary-entries)

this appears to be caused by the 2004-01-09 change

(diary-entry-time):
	Also accept time in the form XX[.XX][am/pm/AM/PM].

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Modern man is the missing link between apes and human beings.

Re: invalid-regexp in calendar

[Thien-Thi Nguyen]

Sam Steingold <sds@gnu.org> writes:

   GNU Emacs 21.3.50.1 (i386-msvc-nt5.0.2195)
    of 2004-01-08 on WINSTEINGOLDLAP
   --with-msvc (12.00)

   Debugger entered--Lisp error: (invalid-regexp "Unmatched ) or \\)")

fixed (spurious left-square-bracket removed) in cvs.

thi

Re: invalid-regexp in calendar

[Ed Reingold]

Who made the change (and why)?


> GNU Emacs 21.3.50.1 (i386-msvc-nt5.0.2195)
>  of 2004-01-08 on WINSTEINGOLDLAP
> --with-msvc (12.00)
> 
> Debugger entered--Lisp error: (invalid-regexp "Unmatched ) or \\)")
>   string-match("\\`[ 	\n\\^M]*\\([0-9]?[0-9]\\)[:.][\\([0-9][0-9]\\)\\([ap]\\)m\\>" "Day 22 of 2004; 344 days remaining in the year")
>   diary-entry-time("Day 22 of 2004; 344 days remaining in the year")
>   diary-entry-compare(((1 22 2004) "Day 22 of 2004; 344 days remaining in the year" "&%%(diary-day-of-year)" #<marker at 2188 in .diary> nil) ((1 22 2004) "Daylight [Eastern Standard Time]: 07:08/16:44 [=9:35] at Boston, MA, USA" "&%%(diary-sunrise-sunset)" #<marker at 1952 in .diary> nil))
>   sort((((1 22 2004) "Hebrew date (until sunset): 5764, Teveth 28" "&%%(diary-hebrew-date)" #<marker at 1929 in .diary> nil)) diary-entry-compare)
>   sort-diary-entries()
>   run-hooks(nongregorian-diary-listing-hook list-diary-entries-hook)
>   list-diary-entries((1 22 2004) 1)
>   view-diary-entries(1)
> * call-interactively(view-diary-entries)
> 
> this appears to be caused by the 2004-01-09 change
> 
> (diary-entry-time):
> 	Also accept time in the form XX[.XX][am/pm/AM/PM].
> 
> -- 
> Sam Steingold (http://www.podval.org/~sds) running w2k
> <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
> <http://www.mideasttruth.com/> <http://www.honestreporting.com>
> Modern man is the missing link between apes and human beings.
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 

Re: invalid-regexp in calendar

[D. Goel]

Ed Reingold <reingold@emr.cs.iit.edu> writes:

> Who made the change (and why)?
>

I believe Thi has diagnosed and fixed this problem already.

PS: I was the one to blame -- had made the change to allow HH.MM in
addition to HH:MM for time, please see archives or changelog :)

[...]

Suggestions for mode-line-format changes

[Kim F. Storm]

Now that the mode-line-position information has been moved
from the end of the mode line, and vc-mode is moved there too,
the space between the buffer name and the mode-line-modes
has become pretty crowded.

Now, if you enable display-time and display-battery,
which adds time and battery status, e.g. 15:57 [95%],
to that part of the mode line as well, it's a total mess.

My suggestion is to move the global-mode-string to the
end of the mode line; the cost is that the time and
battery status isn't always shown (especially in
partial width windows).


Also, I would like to suggest an alternative presentation
of the position, line number, and column number.

The current presentation is like

        L1 C0 Top
        L172 C23 43%
        L341 C0 Bot

which I find quite annoying to look at.

I've been using the following alternative for quite some
time, and I find it much easier on the eyes:

        Top (1,0)
        43% (172,23)
        Bot (341,0)

If only one of line-number-mode or column-number-mode is enabled,
this doesn't make much sense, so I use the following formats:

        Top L1
        43% C23
        Bot L341

To try the suggested format, just execute this (and toggle column and
line number mode as you like):

(let ((help-echo "mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete"))
  (setq-default mode-line-position
    `((-3 . ,(propertize "%p" 'help-echo help-echo))
      (line-number-mode 
       ((column-number-mode
	 (,(propertize " (%l,%c)" 'help-echo help-echo))
	 (,(propertize " L%l" 'help-echo help-echo))))
       ((column-number-mode
	 (,(propertize " C%c" 'help-echo help-echo))))))))


What do you think?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Romain FRANCOISE]

Kim F Storm writes:

> I've been using the following alternative for quite some
> time, and I find it much easier on the eyes:

>         Top (1,0)
>         43% (172,23)
>         Bot (341,0)

The problem with this is that for the newcomer, it's not obvious that
the numbers refer to the current column and line.  I agree that your
solution is compact and acceptable for a trained eye, but I wouldn't
recommend it as a default setting.  And for the record, I like the
current default setting, it's easily readable and clearly
distinguishes line and column numbers, so my vote goes to "status quo"
on this issue.

Just my 2c,

Romain.
-- 
Romain FRANCOISE <romain@orebokech.com> | But you don't care for me and
it's a miracle -- http://orebokech.com/ | I don't care now for anybody.

Re: Suggestions for mode-line-format changes

[Richard Stallman]

Your ideas sound good--would you please go ahead and implement them?

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Your ideas sound good--would you please go ahead and implement them?

Done.

I managed to solve the problem I had with padding of mode-line-position 
(discussed in another mail); the trick was to specify the padding for
the %l/%c part, rather than the whole mode-line-position.

However, I still think it is a bug that we cannot use "precision" on a
mode-line-element nested inside a "padded" mode-line-element.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    However, I still think it is a bug that we cannot use "precision" on a
    mode-line-element nested inside a "padded" mode-line-element.

In principal it would be good to make all features orthogonal, but I
tend to think this is not as important as other things we can do.

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

I wrote:

> Now that the mode-line-position information has been moved
> from the end of the mode line, and vc-mode is moved there too,
> the space between the buffer name and the mode-line-modes
> has become pretty crowded.
> 

Actually, I think the new position of "mode-line-position" in the mode line
is a drawback compared to the former position at the end of the mode line!

Try turning on column-number-mode, goto to the first line of a
non-empty buffer and hold down the right arrow key to advance through
the characters and lines of the buffer.

Notice how the mode line information to the right of the
mode-line-position starts jumping forth and back when the column goes
from 9 to 10 and from the end of line column back to 0.

Likewise, if you just start writing in the buffer, the same jumpyness
is seen in the mode line as you enter the 10th character of a line
and you press RET.

IMO, this is really, really annoying.  I never saw any such jumpyness
with the old position.


I liked the old position better, but if we want to keep it in the new
position, I think padding of the whole mode-line-position
[specified inside mode-line-position itself, of course] should be
added.

Using my suggested format, I tried to add padding like this:

        (setq-default mode-line-position 
                      '((15 (-3 . "%p") " (%l,%c)")))

but this doesn't work as the entire padding is done to the end of the
%p part.

I then tried

        (setq-default mode-line-position 
                      '((15 "" (-3 . "%p") " (%l,%c)")))

but then the "" is padded to 15 spaces which doesn't help either.


The following works by padding at the end of the combined string, but
then the "Bottom" string isn't truncated to "Bot":

(setq-default mode-line-position 
	      '((15 "%p (%l,%c)")))


It seems that it doesn't work to combine padding and trunction like
        (15 (-3 ...) ...)

That's a bug IMO.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Kenichi Handa]

In article <5xk7mlfsvf.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> Now that the mode-line-position information has been moved
> from the end of the mode line, and vc-mode is moved there too,
> the space between the buffer name and the mode-line-modes
> has become pretty crowded.

> Now, if you enable display-time and display-battery,
> which adds time and battery status, e.g. 15:57 [95%],
> to that part of the mode line as well, it's a total mess.

I'd like to display such global information not in the mode
line but, for instance, at the right end of menu bar, or
tool bar if they exist.  Such an area can also be used for
displaying:
	o multibyte or unibyte session
	o current language environment
But, I don't know how it is difficult.

By the way, I'm recently using this code to make Emacs
use frame title for displaying time-string.

(add-hook
 'display-time-mode-hook
 #'(lambda () 
     (setq global-mode-string
	   (delete 'display-time-string global-mode-string))))

(add-hook
 'display-time-hook
 #'(lambda ()
     (modify-frame-parameters 
      nil
      `((title . ,display-time-string)))))

---
Ken'ichi HANDA
handa@etl.go.jp

Re: Suggestions for mode-line-format changes

[Miles Bader]

Kenichi Handa <handa@etl.go.jp> writes:
> > Now, if you enable display-time and display-battery,
> > which adds time and battery status, e.g. 15:57 [95%],
> > to that part of the mode line as well, it's a total mess.
> 
> I'd like to display such global information not in the mode
> line but, for instance, at the right end of menu bar, or
> tool bar if they exist.

Hmm, that seems like a great idea (for global info like that).

I think the menu-bar would be better, since I don't use a tool-bar...:-/

I don't think it would be too hard to hack something like that into the
lucid toolkit that comes with emacs, but I have no idea about other
toolkits.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Kenichi Handa <handa@etl.go.jp> writes:
> > > Now, if you enable display-time and display-battery,
> > > which adds time and battery status, e.g. 15:57 [95%],
> > > to that part of the mode line as well, it's a total mess.
> > 
> > I'd like to display such global information not in the mode
> > line but, for instance, at the right end of menu bar, or
> > tool bar if they exist.
> 
> Hmm, that seems like a great idea (for global info like that).
> 
> I think the menu-bar would be better, since I don't use a tool-bar...:-/
> 
> I don't think it would be too hard to hack something like that into the
> lucid toolkit that comes with emacs, but I have no idea about other
> toolkits.

I guess it could always be done using a "tool-tip" like approach, ie.
by displaying the information in a separate "global-mode-frame".

That would allow users to position that frame on title-bar,
menu-bar, tool-bar, or below the emacs frame; but that could be
used for more things (e.g. ediff frame) and other stuff as well.

Would need some ways to control where that frame is displayed
relative to the currently active emacs frame.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > I don't think it would be too hard to hack something like that into the
> > lucid toolkit that comes with emacs, but I have no idea about other
> > toolkits.
> 
> I guess it could always be done using a "tool-tip" like approach, ie.
> by displaying the information in a separate "global-mode-frame".

Don't want.  I want it in the main window (little independent X windows
are generally pretty icky; see ediff for a particularly stupid and
annoying example).

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: Suggestions for mode-line-format changes

[Kenichi Handa]

In article <buolm70eas1.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
>>  I guess it could always be done using a "tool-tip" like approach, ie.
>>  by displaying the information in a separate "global-mode-frame".

> Don't want.  I want it in the main window (little independent X windows
> are generally pretty icky; see ediff for a particularly stupid and
> annoying example).

If you mean `frame' by `window', I fully agree.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: Suggestions for mode-line-format changes

[Miles Bader]

huug <huug.at.gmane@xs4all.nl> writes:
> > Don't want.  I want it in the main window (little independent X
> > windows are generally pretty icky; see ediff for a particularly
> > stupid and annoying example).
> 
> If you mean ediff should use a more tool-tip like frame, I agree.

No, I mean ediff shouldn't use the stupid little `command frame'.
It shouldn't use any new frames at all, it should just make the ediff
commands available in the two buffers being diffed.

[ediff's user interface seems generally pretty bad; I like the
functionality, but never use it because it drives me nuts every time I
try]

-Miles
-- 
80% of success is just showing up.  --Woody Allen

ediff user interface (Re: Suggestions for mode-line-format changes)

[Karl Eichwalder]

Miles Bader <miles@lsi.nec.co.jp> writes:

> No, I mean ediff shouldn't use the stupid little `command frame'.

One can get used to it, believe me :)

> It shouldn't use any new frames at all, it should just make the ediff
> commands available in the two buffers being diffed.

But then it is impossible to edit buffer A or B directly.  I you don't
want the command frame you either will have to make use of complicate
key combos or toggle between an edit and a command mode (like vi).
Maybe, toggling mode isn't that bad.

The features are basically there (start Emacs with -nw and call ediff),
but it isn't that easy to customize ediff.

> [ediff's user interface seems generally pretty bad; I like the
> functionality, but never use it because it drives me nuts every time I
> try]

It's a challenge to work with ediff but also it's fun!

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: ediff user interface (Re: Suggestions for mode-line-format changes)

[Andreas Schwab]

Karl Eichwalder <keichwa@gmx.net> writes:

|> Miles Bader <miles@lsi.nec.co.jp> writes:
|> 
|> > No, I mean ediff shouldn't use the stupid little `command frame'.
|> 
|> One can get used to it, believe me :)
|> 
|> > It shouldn't use any new frames at all, it should just make the ediff
|> > commands available in the two buffers being diffed.
|> 
|> But then it is impossible to edit buffer A or B directly.  I you don't
|> want the command frame you either will have to make use of complicate
|> key combos or toggle between an edit and a command mode (like vi).
|> Maybe, toggling mode isn't that bad.

I'm using

(setq ediff-merge-split-window-function 'split-window-vertically)
(setq ediff-window-setup-function 'ediff-setup-windows-plain)

and it works quite well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    [ediff's user interface seems generally pretty bad; I like the
    functionality, but never use it because it drives me nuts every time I
    try]

I feel the same--I tried it once and got too confused.

I don't know whether fixing this would require major changes
or perhaps just fixing a few details.

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     [ediff's user interface seems generally pretty bad; I like the
>     functionality, but never use it because it drives me nuts every time I
>     try]
> 
> I feel the same--I tried it once and got too confused.
> 
> I don't know whether fixing this would require major changes
> or perhaps just fixing a few details.

I'd suggest giving it another try.  The GUI is a little akward to get
used to, but ediif is really too good to reject simply because of that.

I couldn't live without it; on the projects I work on I often have to
install bug fixes on several release brances, and ediff makes that
quite easy!


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Miles Bader]

On Mon, Aug 26, 2002 at 01:36:10AM +0200, Kim F. Storm wrote:
> I'd suggest giving it another try.  The GUI is a little akward to get
> used to, but ediff is really too good to reject simply because of that.

So the best solution would be the same functionality with a better UI.

-miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Suggestions for mode-line-format changes

[Michael Kifer]

Somebody>     [ediff's user interface seems generally pretty bad; I like the
Somebody>     functionality, but never use it because it drives me nuts every time I
Somebody>     try]

RMS> I feel the same--I tried it once and got too confused.
RMS> 
RMS> I don't know whether fixing this would require major changes
RMS> or perhaps just fixing a few details.

Kim Storm> I'd suggest giving it another try.  The GUI is a little akward to get
Kim Storm> used to, but ediff is really too good to reject simply because of that.

Miles Bader> So the best solution would be the same functionality with a better UI.


I am open to suggestions, but I don't have much time to make major changes.
Couple of times (the above is perhaps the third) I received general
complaints about how bad ediff UI is (in almost exactly the same words as
above with no useful info attached), but when I asked to be more specific the
complainers did not bother to reply.

	--michael 


PS. On the other hand, I receive tons of email attesting to the contrary.

PPS. I am also not averse to the idea that somebody takes over the maintenance of
     ediff.

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> Somebody>     [ediff's user interface seems generally pretty bad; I
> Somebody>     like the functionality, but never use it because it
> Somebody>     drives me nuts every time I try]
> 
> I am open to suggestions, but I don't have much time to make major changes.

I don't think anybody expects you to, certainly not without a real plan,
and hopefully anyone who really wants a change would do the work.

Anyway, though I don't like ediff's UI, it's not entirely clear to me
what a better UI would look like; perhaps discussion could turn up
some ideas.

I think my main problem with ediff is that it seems way too stateful --
it sets up an `ediff session' and puts up a special `control frame' (or
window), and generally seems very heavyweight.  I guess many people like
this (it's sort of like many dedicated GUI diff programs), but I don't;
it's very un-emacsy.  When I see all that state, I worry what happens if
I forget that I'm ediffing and delete a buffer or change a buffer, &c.
Maybe this worry is unwarranted, but I think it's kind of natural given
the general style of the ediff UI.

Compared to other programs, emacs gives the user much more freedom over
the configuration of windows, etc., and the ability to freely switch to
other tasks, so very stateful UIs often cause problems.

[The same `stateful' complaint could be made about e.g. Gnus, but I find
that when I want to use ediff, I also want to mess with CVS, visit other
source files, etc., and generally mess up the nice window configuration
ediff set up; this doesn't generally seem to happen with Gnus.]

I'd prefer that _all_ ediff state be contained within the two buffers
being diffed; if I kill them both, poof, no more ediff state (if I kill
only one, who knows, but presumably an error when you try to perform an
ediff operation).  [Maybe this is the case already, and I'm being fooled
by the appearance of the UI; what happens when you try two simulaneous
ediff sessions, for instance?]

This of course means that something has to be done about ediff commands;
I'd be happy with a simple command-mode vs. edit-mode toggle (look at
`diff-mode' for a particularly elegant implementation, BTW -- it puts
all the special single-letter command shortcuts on a minor-mode keymap
enabled by `buffer-read-only', so when the file's editable, you can edit
it, and you can just do toggle-read-only to get the convenient shortcut
commands).

Anyway, that's my take.

> PS. On the other hand, I receive tons of email attesting to the contrary.

Well, I think there's no doubt that ediff contains some great
functionality.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Suggestions for mode-line-format changes

[Michael Kifer]

Miles,
If I understand you correctly, almost everything that you have described is
already there and is available from the menus.

80% of ediff's functionality can be figured out without reading the
manual. Did you ever try to hit the "?" mark in that small window or try to
experiment with Menubar.Tools."Ediff Miscellanea"?
But RTFM is always a good idea.

Anyway, if you have a better design, the field is wide open. I just want
to air my opinion on one suggestion of yours: If all the state is contained
in *both* buffers (or 3 buffers), as you suggest, then it is a *bad*
idea. The state should be in *one* buffer, as it is in Ediff. It was
designed this way because it is important to be able to run multiple
simultaneous diffing sessions that involve overlapping buffers or
parts of buffers.

One thing that Ediff doesn't do (among the things that you have listed) is
to give the user complete control of how exactly the windows should look
like. It has its own idea (although it is more flexible than you probably
think). But if you RTMF, you will see that all this is just one
variable/function, which you can customize. If you have the time and a
design, you can write your own window setup function and offer it to the
world.


	--michael 


> Michael Kifer <kifer@cs.sunysb.edu> writes:
> > Somebody>     [ediff's user interface seems generally pretty bad; I
> > Somebody>     like the functionality, but never use it because it
> > Somebody>     drives me nuts every time I try]
> > 
> > I am open to suggestions, but I don't have much time to make major changes.
> 
> I don't think anybody expects you to, certainly not without a real plan,
> and hopefully anyone who really wants a change would do the work.
> 
> Anyway, though I don't like ediff's UI, it's not entirely clear to me
> what a better UI would look like; perhaps discussion could turn up
> some ideas.
> 
> I think my main problem with ediff is that it seems way too stateful --
> it sets up an `ediff session' and puts up a special `control frame' (or
> window), and generally seems very heavyweight.  I guess many people like
> this (it's sort of like many dedicated GUI diff programs), but I don't;
> it's very un-emacsy.  When I see all that state, I worry what happens if
> I forget that I'm ediffing and delete a buffer or change a buffer, &c.
> Maybe this worry is unwarranted, but I think it's kind of natural given
> the general style of the ediff UI.
> 
> Compared to other programs, emacs gives the user much more freedom over
> the configuration of windows, etc., and the ability to freely switch to
> other tasks, so very stateful UIs often cause problems.
> 
> [The same `stateful' complaint could be made about e.g. Gnus, but I find
> that when I want to use ediff, I also want to mess with CVS, visit other
> source files, etc., and generally mess up the nice window configuration
> ediff set up; this doesn't generally seem to happen with Gnus.]
> 
> I'd prefer that _all_ ediff state be contained within the two buffers
> being diffed; if I kill them both, poof, no more ediff state (if I kill
> only one, who knows, but presumably an error when you try to perform an
> ediff operation).  [Maybe this is the case already, and I'm being fooled
> by the appearance of the UI; what happens when you try two simulaneous
> ediff sessions, for instance?]
> 
> This of course means that something has to be done about ediff commands;
> I'd be happy with a simple command-mode vs. edit-mode toggle (look at
> `diff-mode' for a particularly elegant implementation, BTW -- it puts
> all the special single-letter command shortcuts on a minor-mode keymap
> enabled by `buffer-read-only', so when the file's editable, you can edit
> it, and you can just do toggle-read-only to get the convenient shortcut
> commands).
> 
> Anyway, that's my take.
> 
> > PS. On the other hand, I receive tons of email attesting to the contrary.
> 
> Well, I think there's no doubt that ediff contains some great
> functionality.
> 
> -Miles
> -- 
> `...the Soviet Union was sliding in to an economic collapse so comprehensive
>  that in the end its factories produced not goods but bads: finished products
>  less valuable than the raw materials they were made from.'  [The Economist]
> 

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> If I understand you correctly, almost everything that you have described is
> already there and is available from the menus.

Well, either you don't understand me correctly, or else the menus and
documentation (which I did read) are designed for those smarter or more
patient than I.  As far as I can see, _none_ of what I described is
available.

In particular, it appears that you _always_ need a control frame/window,
and that ediff commands _only_ work in the control frame/window (even if
I type `M-x ediff-next-difference' in one of the buffers being diffed,
it just gives me an error saying that).

> 80% of ediff's functionality can be figured out without reading the
> manual.  Did you ever try to hit the "?" mark in that small window or
> try to experiment with Menubar.Tools."Ediff Miscellanea"?
> But RTFM is always a good idea.

Of course.  It shows lots of handy commands -- but `how to find ediff
commands' wasn't what I was complaining about.

> If all the state is contained in *both* buffers (or 3 buffers), as you
> suggest, then it is a *bad* idea.  The state should be in *one*
> buffer, as it is in Ediff.  It was designed this way because it is
> important to be able to run multiple simultaneous diffing sessions
> that involve overlapping buffers or parts of buffers.

It sounds like the best thing to do is have all ediff state contained
in a lisp value, which is pointed to by whatever buffers, but
presumably this would be a big change to the code.

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: Suggestions for mode-line-format changes

[Michael Kifer]

Miles Bader <miles@gnu.org> said:
>
> Michael Kifer <kifer@cs.sunysb.edu> writes:
> > If I understand you correctly, almost everything that you have described is
> > already there and is available from the menus.
> 
> Well, either you don't understand me correctly, or else the menus and
> documentation (which I did read) are designed for those smarter or more
> patient than I.  As far as I can see, _none_ of what I described is
> available.
> 
> In particular, it appears that you _always_ need a control frame/window,
> and that ediff commands _only_ work in the control frame/window (even if
> I type `M-x ediff-next-difference' in one of the buffers being diffed,
> it just gives me an error saying that).

Yes, you always need the control buffer. But you can hide it and the other
windows if you need to do something else. There is a mechanism to easily
find suspended ediff sessions and resume them. Your complaint was about the
inability to switch to other emacs jobs and I am saying that this is not the
case.

It seems that none of what you explicitly listed in your original message
is the real problem. Instead, you are complaining about the design decision
that the small control window must be present at all times.

In this regard, I think you might not have understood what I said about a
bad suggestion in your previous message. The same buffer can be involved in
different ediff sessions.  I consider this essential. You can't just start
typing commands into a buffer being diffed without first indicating which
session the buffer is involved in is current.

The UI by which you indicate this is not present in ediff, but can be
added, because each buffer already knows the set of sessions it is in.
However, I won't be the one to implement this because I think it is going
to be confusing and is not necessary.

> > If all the state is contained in *both* buffers (or 3 buffers), as you
> > suggest, then it is a *bad* idea.  The state should be in *one*
> > buffer, as it is in Ediff.  It was designed this way because it is
> > important to be able to run multiple simultaneous diffing sessions
> > that involve overlapping buffers or parts of buffers.
> 
> It sounds like the best thing to do is have all ediff state contained
> in a lisp value, which is pointed to by whatever buffers, but
> presumably this would be a big change to the code.

It is already contained in one place -- the control buffer.
It is possible to make this buffer invisible as I indicated above and
instead implement a mechanism by which you indicate the current control session.
But I think this is a bad idea. This is how emerge works, and I don't like
its interface. I want to be able to edit the buffers without typing special
commands by just moving the mouse there.



	--michael 

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> In this regard, I think you might not have understood what I said about a
> bad suggestion in your previous message.

No, I understood what you meant.

> The same buffer can be involved in different ediff sessions.  I
> consider this essential.  You can't just start typing commands into a
> buffer being diffed without first indicating which session the buffer
> is involved in is current.

Sure, it's true that the current UI might be best for very complex
situations like that -- but frankly, for me at least, the default is
_very simple_ situations, where it _is_ quite reasonable to have a
unique mapping of text-buffer->ediff-session.

I'd be happy if ediff could give me my preferred UI most of the time,
but require me switch to the complex UI for those (very, very, rare)
circumstances when I need to.

> The UI by which you indicate this is not present in ediff, but can be
> added, because each buffer already knows the set of sessions it is in.

Ok.  If I get around too it, I'll see if I can add enough features to
ediff to allow it to use an interface like I've described.

> It is already contained in one place -- the control buffer.  It is
> possible to make this buffer invisible as I indicated above and
> instead implement a mechanism by which you indicate the current
> control session.

I'd like it so that command in one of the source buffers simply mapped
to the control buffer, which would stay hidden (even when `in use').

> But I think this is a bad idea. This is how emerge works, and I don't
> like its interface.

That's OK; we're even, I guess... :-)

-Miles
-- 
Run away!  Run away!

Re: Suggestions for mode-line-format changes

[Michael Kifer]

>>>>> "Miles" == Message from Miles Bader <<miles@lsi.nec.co.jp> > writes:

    >> It is already contained in one place -- the control buffer.  It is
    >> possible to make this buffer invisible as I indicated above and
    >> instead implement a mechanism by which you indicate the current
    >> control session.

    Miles> I'd like it so that command in one of the source buffers simply mapped
    Miles> to the control buffer, which would stay hidden (even when `in use').

This info is present, since each buffer has a local var that contain the
list of control buffers of the ediff sessions related to it.

    >> But I think this is a bad idea. This is how emerge works, and I don't
    >> like its interface.

    Miles> That's OK; we're even, I guess... :-)

Grin. But I wasn't trying to get at you. I really actively disliked emerge's
interface, which was one of the reasons why I didn't use it, while at the
same time stealing many other ideas from this package.


	--michael 

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
>     Miles> I'd like it so that command in one of the source buffers
>     Miles> simply mapped to the control buffer, which would stay
>     Miles> hidden (even when `in use').
> 
> This info is present, since each buffer has a local var that contain the
> list of control buffers of the ediff sessions related to it.

Ok; so perhaps the following would suffice:

  * A minor-mode that just contains a keymap full of appropriate
    commands that redirect to the first ediff control-buffer in the list
    (perhaps conditionalized on buffer-read-only like in diff-mode).
    It looks like `ediff-prepare-buffer-hook' could be used to turn on
    the minor mode in each source buffer.

  * An ediff window-configuration function that always keeps the
    control-window hidden.

-Miles
-- 
97% of everything is grunge

Re: Suggestions for mode-line-format changes

[Michael Kifer]

> Michael Kifer <kifer@cs.sunysb.edu> writes:
> >     Miles> I'd like it so that command in one of the source buffers
> >     Miles> simply mapped to the control buffer, which would stay
> >     Miles> hidden (even when `in use').
> > 
> > This info is present, since each buffer has a local var that contain the
> > list of control buffers of the ediff sessions related to it.
> 
> Ok; so perhaps the following would suffice:
> 
>   * A minor-mode that just contains a keymap full of appropriate
>     commands that redirect to the first ediff control-buffer in the list
>     (perhaps conditionalized on buffer-read-only like in diff-mode).
>     It looks like `ediff-prepare-buffer-hook' could be used to turn on
>     the minor mode in each source buffer.
> 
>   * An ediff window-configuration function that always keeps the
>     control-window hidden.
> 
> -Miles

Pretty much. However, I think that defaulting to one of the active control
sessions is no good. Could be too confusing and frustrating.
Need a mechanism to set the default session.

Any takers? :-)

m

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> >   * A minor-mode that just contains a keymap full of appropriate
> >     commands that redirect to the first ediff control-buffer in the list
> >     (perhaps conditionalized on buffer-read-only like in diff-mode).
> >     It looks like `ediff-prepare-buffer-hook' could be used to turn on
> >     the minor mode in each source buffer.
> 
> Pretty much.  However, I think that defaulting to one of the active control
> sessions is no good.  Could be too confusing and frustrating.
> Need a mechanism to set the default session.

I think that 99% of the time, the control-buffer list will only have one
entry anyway, and it's obviously harmless to `default' in _that_ case!

I also think it's a good idea to worry about the common case before the
worst case, especially since the worst case is already covered, by the
existing control-window mechanism.

Note that:

  * I'm not suggesting that this minor-mode be turned on by default,
    just that it be available for people like me that don't like the
    normal UI (though perhaps with the `buffer-read-only'
    conditionalization, it wouldn't hurt to have it on by default).

  * If the control buffer isn't hidden, you can use it just like
    always, so no functionality is really lost.  I suspect that if
    people start having multiple simultaneous ediffs on the same
    buffer, they're going to want to use the control-buffer windows
    anyway, for the reasons you gave earlier.

    If they want to use the source-buffer minor-mode commands in
    _addition_ to the control-buffer in a `complex' ediff situation, a
    good solution might be to simply reorder each source-buffer's
    control-buffer list everytime an ediff command is given, so that the
    command-giving control-buffer is first in the source-buffer's list.

    This way, the `ediff session' invoked by the minor-mode will always
    be the most recent one invoked via control-buffer, without needing
    any additional command for setting defaults or whatever.  This seems
    like a straight-forward solution that will usually do the right
    thing even in complex cases.

-miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Suggestions for mode-line-format changes

[Michael Kifer]

> Michael Kifer <kifer@cs.sunysb.edu> writes:
> > >   * A minor-mode that just contains a keymap full of appropriate
> > >     commands that redirect to the first ediff control-buffer in the list
> > >     (perhaps conditionalized on buffer-read-only like in diff-mode).
> > >     It looks like `ediff-prepare-buffer-hook' could be used to turn on
> > >     the minor mode in each source buffer.
> > 
> > Pretty much.  However, I think that defaulting to one of the active control
> > sessions is no good.  Could be too confusing and frustrating.
> > Need a mechanism to set the default session.
> 
> I think that 99% of the time, the control-buffer list will only have one
> entry anyway, and it's obviously harmless to `default' in _that_ case!
> 
> I also think it's a good idea to worry about the common case before the
> worst case, especially since the worst case is already covered, by the
> existing control-window mechanism.
> 
> Note that:
> 
>   * I'm not suggesting that this minor-mode be turned on by default,
>     just that it be available for people like me that don't like the
>     normal UI (though perhaps with the `buffer-read-only'
>     conditionalization, it wouldn't hurt to have it on by default).
> 
>   * If the control buffer isn't hidden, you can use it just like
>     always, so no functionality is really lost.  I suspect that if
>     people start having multiple simultaneous ediffs on the same
>     buffer, they're going to want to use the control-buffer windows
>     anyway, for the reasons you gave earlier.
> 
>     If they want to use the source-buffer minor-mode commands in
>     _addition_ to the control-buffer in a `complex' ediff situation, a
>     good solution might be to simply reorder each source-buffer's
>     control-buffer list everytime an ediff command is given, so that the
>     command-giving control-buffer is first in the source-buffer's list.
> 
>     This way, the `ediff session' invoked by the minor-mode will always
>     be the most recent one invoked via control-buffer, without needing
>     any additional command for setting defaults or whatever.  This seems
>     like a straight-forward solution that will usually do the right
>     thing even in complex cases.
> 
> -miles

I don't know. I don't like programs that know better than I what I should
be doing. Note also that if you have 2 buffers, the order of ediff sessions
in which they are involved might be different. This would lead to even more
confusion. I just don't see the benefits. All these complications
for the privilege of being able to hold your mouse over a different window
than now?

Of course, if you implement it and people like this -- all the power to you!


	--michael

Re: Suggestions for mode-line-format changes

[Miles Bader]

kifer@cs.stonybrook.edu (Michael Kifer) writes:
> I don't know.  I don't like programs that know better than I what I should
> be doing.

I think the heuristic I mentioned would probably be right almost all of
the time (and _all of the time_ for the overwhelmingly common case where
you're not doing simultaneous ediffs on the same file).

> Note also that if you have 2 buffers, the order of ediff sessions in
> which they are involved might be different.  This would lead to even
> more confusion.

Perhaps -- in the case where you have multiple simultaneous ediffs with
overlapping sets of buffers.  How often do you do this?

[In fact, I think the `most recent' behavior would be fairly reasonable,
even in this case]

You seem to be saying `Look, in this highly complex case, it will be
confusing!  Abort!'

This seems odd for two reasons -- 

 (1) I think most people use ediff in a fairly simple way, so wouldn't
     it be good to optimize for that?  One way to do this is to provide
     good defaults (and perhaps a way to override them for unusual cases).

 (2) The cases you mention, with multiple overlapping ediff sessions,
     are simply confusing, full-stop, regardless of what this minor-mode
     does.  You're probably better off using the control-window in such
     cases.

     Maybe you could make it a bit better by providing ways to override
     the defaults for such rare situations, but it doesn't mean you
     should avoid defaults altogether.

> I just don't see the benefits.  All these complications for the
> privilege of being able to hold your mouse over a different window
> than now?

Er, I don't use a mouse very much when I use emacs.  Perhaps that's one
reason why I'm annoyed by ediff's interface and you're not.

Anyway, where you see `complications' I see refreshing simplicity.

-Miles
-- 
97% of everything is grunge

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> kifer@cs.stonybrook.edu (Michael Kifer) writes:
> > I don't know.  I don't like programs that know better than I what I should
> > be doing.
> 
> I think the heuristic I mentioned would probably be right almost all of
> the time (and _all of the time_ for the overwhelmingly common case where
> you're not doing simultaneous ediffs on the same file).

For me, it would work 100%.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Michael Kifer <kifer@cs.sunysb.edu> writes:
> >     Miles> I'd like it so that command in one of the source buffers
> >     Miles> simply mapped to the control buffer, which would stay
> >     Miles> hidden (even when `in use').
> > 
> > This info is present, since each buffer has a local var that contain the
> > list of control buffers of the ediff sessions related to it.
> 
> Ok; so perhaps the following would suffice:
> 
>   * A minor-mode that just contains a keymap full of appropriate
>     commands that redirect to the first ediff control-buffer in the list
>     (perhaps conditionalized on buffer-read-only like in diff-mode).
>     It looks like `ediff-prepare-buffer-hook' could be used to turn on
>     the minor mode in each source buffer.

For my normal ediff usage, the 'read-only' is command mode idea is
really quite interesting.

I use CVSREAD=y, i.e. my cvs files any normally checked out read-only.
Only when I do "C-x v v", the file becomes writeable.

Now, if I want to merge a change from one branch of the CVS tree, I first
commit the changes on one branch, leaving the buffer containing the modified
file read-only.

I then open the file from the other branch and do C-x v v to make that revision
writeable.

This means that in one window I have the file _with modifications_
that I need to merge from (the source buffer) which is read-only, and
in another window I have the file _without modifications_ which need
to be patched (the target buffer) which is writeable.

Now, with Miles' idea, I can freely edit the writeable target buffer
using all my usual emacs commands without worrying about ediff, and to
emit ediff commands, I simply switch to the read-only source buffer
where the minor-mode keymap gives instant access to the ediff commands.

Since this is how I use ediff 99% of the time, I'd love a simplified
GUI like that!

And although I've used ediff for years (and love it for the things it
can do) I have never used multiple ediff sessions.

> 
>   * An ediff window-configuration function that always keeps the
>     control-window hidden.
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Alan Shutko]

storm@cua.dk (Kim F. Storm) writes:

> I guess it could always be done using a "tool-tip" like approach, ie.
> by displaying the information in a separate "global-mode-frame".

So, where does it go when the user is on a text terminal?  Does it
just disappear?

I don't really like this approach for the default.  As options, yes.
(And add in the option to put it in the terminal status line or the
titlebar.)  But I'm not convinced that requiring the user to decide
where a little floating frame will do the least damage (ie, cover up
things that are less likely to be important) is a good thing.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Beware of people that put numbers after their names.

Re: Suggestions for mode-line-format changes

[Alan Shutko]

huug <huug.at.gmane@xs4all.nl> writes:

> Eheh. And if you're not using a text console, you usually have better
> options then global-mode-line, I think. DockApplets like wmCalClock,
> WMMail and wmcpuload you can see on all your Workspaces, not just the
> one Emacs uses.

Huh?  You don't have an Emacs window on every workspace?  Actually, I
got rid of all my apps in favor of the mode-line, since it takes up
less space.

> Speaking of Workspaces, I think there's a bug here: no matter which
> one I start Emacs from, it creates its frame in #1.  Or would that
> be WindowMakers fault?

I'm fairly sure that it's Windowmaker's fault....

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Wisdom is rarely found on the best-seller list.

Re: Suggestions for mode-line-format changes

[Glenn Morris]

huug wrote:

> Speaking of Workspaces, I think there's a bug here: no matter which
> one I start Emacs from, it creates its frame in #1.  Or would that be
> WindowMakers fault?

It doesn't do that for me - Emacs appears in the workspace where I started
it. Maybe you have told WindowMaker to always start Emacs in workspace 1?
To check:
Right-click on the WM title bar of an Emacs window, choose Attributes, then
"Icon and Initial Workspace" from the menu. Is the "Initial Workspace" item
set to "Nowhere in particular"?

And just to add my tuppence worth to the whole "mode-line" business, I have
put the time and date in a mode-line tooltip via display-time-string-forms,
which saves space in the mode-line and stops me clock-watching, as the
clock only appears when I want it to. No use for console mode of course
though, as has been said.

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Kenichi Handa <handa@etl.go.jp> writes:

> In article <5xk7mlfsvf.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> > Now that the mode-line-position information has been moved
> > from the end of the mode line, and vc-mode is moved there too,
> > the space between the buffer name and the mode-line-modes
> > has become pretty crowded.
> 
> > Now, if you enable display-time and display-battery,
> > which adds time and battery status, e.g. 15:57 [95%],
> > to that part of the mode line as well, it's a total mess.
> 
> I'd like to display such global information not in the mode
> line but, for instance, at the right end of menu bar, or
> tool bar if they exist.

I had the same thought, but didn't have any clue how to do it.

Actually, when I was working on the MS-DOG port a long time ago
I added the ability to display the time at the far right of
the menu bar.  It worked by writing directly to the relevant
addresses in VGA memory, so it's no wonder that code has been
removed since then :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Alan Shutko]

Kenichi Handa <handa@etl.go.jp> writes:

> I'd like to display such global information not in the mode
> line but, for instance, at the right end of menu bar, or
> tool bar if they exist.  

No.  This information is important to the user (otherwise the user
would not have turned it on).  Putting it at the end of anything, be
it the mode-line, the menu bar, or the tool bar, will sometimes lose
this information if the toolbar or menubar is too long (which often,
it is).


-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Who the hell cares where Carmen Sandiego is?

Re: Suggestions for mode-line-format changes

[Kenichi Handa]

In article <87znvd1qkr.fsf@wesley.springies.com>, Alan Shutko <ats@acm.org> writes:
> Kenichi Handa <handa@etl.go.jp> writes:
>>  I'd like to display such global information not in the mode
>>  line but, for instance, at the right end of menu bar, or
>>  tool bar if they exist.  

> No.  This information is important to the user (otherwise the user
> would not have turned it on).  Putting it at the end of anything, be
> it the mode-line, the menu bar, or the tool bar, will sometimes lose
> this information if the toolbar or menubar is too long (which often,
> it is).

I mean "... at the right end of menu bar ... overriding the
other data".  So, if that is implemented, we don't loose
that information.  It may be better that the hidden part
appears (by hiding display-time-string) when one moves mouse
to the area in the menu bar where normal menus are
displayed.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: Suggestions for mode-line-format changes

[Stefan Monnier]

> I mean "... at the right end of menu bar ... overriding the
> other data".  So, if that is implemented, we don't loose
> that information.  It may be better that the hidden part
> appears (by hiding display-time-string) when one moves mouse
> to the area in the menu bar where normal menus are
> displayed.

I kind of like the idea of putting global info somewhere else than the
modeline, but I can't resist pointing out that Motif's menubar has the
`Help' menu stuck all the way to the right hand side (and I actually
like it and find that the Lucid toolkit should be improved to do the
same).  Hiding it while the mouse is away might not be such a good idea.

	
	Stefan

Re: Suggestions for mode-line-format changes

[Kenichi Handa]

In article <200208251823.g7PINIZ21246@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> I kind of like the idea of putting global info somewhere else than the
> modeline, but I can't resist pointing out that Motif's menubar has the
> `Help' menu stuck all the way to the right hand side (and I actually
> like it and find that the Lucid toolkit should be improved to do the
> same).  Hiding it while the mouse is away might not be such a good idea.

Oops.  In such a situation, I agree.

By the way, what happens if there are more menus than what
fit in a line?  Does `help' menu override the others?

---
Ken'ichi HANDA
handa@etl.go.jp

Re: Suggestions for mode-line-format changes

[Stefan Monnier]

> In article <200208251823.g7PINIZ21246@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > I kind of like the idea of putting global info somewhere else than the
> > modeline, but I can't resist pointing out that Motif's menubar has the
> > `Help' menu stuck all the way to the right hand side (and I actually
> > like it and find that the Lucid toolkit should be improved to do the
> > same).  Hiding it while the mouse is away might not be such a good idea.
> 
> Oops.  In such a situation, I agree.
> 
> By the way, what happens if there are more menus than what
> fit in a line?  Does `help' menu override the others?

It spreads over more lines ;-)


	Stefan

Re: Suggestions for mode-line-format changes

[Alan Shutko]

storm@cua.dk (Kim F. Storm) writes:

> My suggestion is to move the global-mode-string to the
> end of the mode line; the cost is that the time and
> battery status isn't always shown (especially in
> partial width windows).

I've just updated to your changes, and I really don't like them.  In
one file, it took me from having everything in the modeline displaying
on an 80-character-wide window to losing half of my battery status.

People put stuff in global-mode-string because they always want to
see them.  They don't want to lose it because the mode-string is too
long!  

Personally, I think that the global-mode-string information is more
important to me than the modes, and this new change is exactly
opposite my priorities.  I think that most people would probably agree
with me.  Can we have a survey of some sort to decide whether to keep
this change?  (Right now, I yanked the entire mode-line setup out of
the old bindings.el, but that means I lose out on actual
improvements.)

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Hell, I don't know. Just ask me, I'll tell ya.

Re: Suggestions for mode-line-format changes

[Bill White]

On Fri Aug 23 2002 at 11:33, Alan Shutko <ats@acm.org> said:

> Personally, I think that the global-mode-string information is more
> important to me than the modes, and this new change is exactly
> opposite my priorities.  I think that most people would probably
> agree with me.  Can we have a survey of some sort to decide whether
> to keep this change?  (Right now, I yanked the entire mode-line
> setup out of the old bindings.el, but that means I lose out on
> actual improvements.)

I'm with Alan.  Since time immemorial (or, like, 1992) I've looked at
one place on the screen to get the time and date.  Now it's way over
there somewhere, if I'm lucky and haven't done C-x 3.

bw
-- 
Bill White                                               Office: 5N-X30
Documentation Programmer                      Phone: 217-398-0700 x 234
Wolfram Research                                      Fax: 217-398-0747
http://members.wri.com/billw        Office hours: 4am-noon Mon-Wed, Fri

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Bill White <billw@wolfram.com> writes:

> On Fri Aug 23 2002 at 11:33, Alan Shutko <ats@acm.org> said:
> 
> > Personally, I think that the global-mode-string information is more
> > important to me than the modes, and this new change is exactly
> > opposite my priorities.  I think that most people would probably
> > agree with me.

I guess most users will agree that knowing the time is
important around lunch time and near the end of the day :-)

> >  Can we have a survey of some sort to decide whether
> > to keep this change?  (Right now, I yanked the entire mode-line
> > setup out of the old bindings.el, but that means I lose out on
> > actual improvements.)
> 
> I'm with Alan.  Since time immemorial (or, like, 1992) I've looked at
> one place on the screen to get the time and date.  Now it's way over
> there somewhere, if I'm lucky and haven't done C-x 3.

Well for many years, I've looked near the end of the mode line for
the line and column number ... and they just moved too.

If they had sayed put, this would never have become an issue :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Alan Shutko]

storm@cua.dk (Kim F. Storm) writes:

> I guess most users will agree that knowing the time is
> important around lunch time and near the end of the day :-)

It's also mail, battery status, and upcoming appointments for me.
Some packages I don't personally use which seem to use
global-mode-string include timeclock and viper.

> Well for many years, I've looked near the end of the mode line for
> the line and column number ... and they just moved too.
>
> If they had sayed put, this would never have become an issue :-)

If that's causing this many problems, maybe they should be moved
back, and we continue with the plans to allow customize to do
mode-line-format things.

I'm not sure what the best default for the mode-line is, but I'm not
sure we're improving it for the common case....

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Auditorium: Derived from 'audio' (to hear) and 'taurus' (bull).

Re: Suggestions for mode-line-format changes

[Eli Zaretskii]

On Sun, 25 Aug 2002, Alan Shutko wrote:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I guess most users will agree that knowing the time is
> > important around lunch time and near the end of the day :-)
> 
> It's also mail, battery status, and upcoming appointments for me.
> Some packages I don't personally use which seem to use
> global-mode-string include timeclock and viper.

How about making the mode line taller when the info it should display 
exceeds some threshold?  (Yes, on a tty that would mean the mode line 
will use two screen lines.)

Re: Suggestions for mode-line-format changes

[Miles Bader]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> How about making the mode line taller when the info it should display 
> exceeds some threshold?  (Yes, on a tty that would mean the mode line 
> will use two screen lines.)

Given that the overflow is usually much less that a line's worth of
data, that would be a pretty big cost, unless the threshold were so
large that it would rarely be crossed (and imagine if the mode-lines for
all of your windows were two line; I think most people would prefer
truncate...)

-Miles
-- 
I have seen the enemy, and he is us.  -- Pogo

Re: Suggestions for mode-line-format changes

[Miles Bader]

huug <huug.at.gmane@xs4all.nl> writes:
> And no, I'm not against changing things, but changes should be well
> thought out and the current user base ought to be able to retain the
> old behaviour with one custom setting (mentioned in NEWS).

If there are specific things you dislike, you should name them
explicitly.

Most changes to the mode-line seem to have been fairly minor, so it
hardly seems to be worth the trouble to add options to revert them
(since a user who _really_ objects can always define their own mode-line
format).  Of course, some are more major, e.g. the recent (and IMHO bad)
change to the location of line-numbers.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: Suggestions for mode-line-format changes

[Alan Shutko]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Of course, some are more major, e.g. the recent (and IMHO bad)
> change to the location of line-numbers.

If we're keeping a list, another major change is the move to
global-mode-string.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
DOS 6.0: Bug City !

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Alan Shutko <ats@acm.org> writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> > Of course, some are more major, e.g. the recent (and IMHO bad)
> > change to the location of line-numbers.
> 
> If we're keeping a list, another major change is the move to
> global-mode-string.

As I've said before, my only reason for moving the global-mode-string
to the end of the string was the [IMO unnecessary] move of the line
numbers to the middle of the mode-line [which then became totally
over-crowded].

I'm all in favour of swapping them back to where they used to live!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Alan Shutko <ats@acm.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I guess most users will agree that knowing the time is
> > important around lunch time and near the end of the day :-)
> 
> It's also mail, battery status, and upcoming appointments for me.
> Some packages I don't personally use which seem to use
> global-mode-string include timeclock and viper.

IMO, showing the global-mode-string only once makes sense.
Having it in every window seems to be overkill.

So what about making the global-mode-string appear to the right in the
echo area when it is not in use for other purposes?

That (usually) empty line at the bottom of your screen could easily
show the time and battery status without too much eye strain...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Alan Shutko]

storm@cua.dk (Kim F. Storm) writes:

> So what about making the global-mode-string appear to the right in the
> echo area when it is not in use for other purposes?

That might be nice.  I think I like it.  That would also let it
expand to the full width of the echo area when needed, without
bashing things off the mode-line as it used to do.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Sits he on ever so high a throne, a man still sits on his bottom.

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    So what about making the global-mode-string appear to the right in the
    echo area when it is not in use for other purposes?

I had the same idea this morning.  I think it would be good to try it
and see how well it goes.  Do you want to try it?

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     So what about making the global-mode-string appear to the right in the
>     echo area when it is not in use for other purposes?
> 
> I had the same idea this morning.  I think it would be good to try it
> and see how well it goes.  Do you want to try it?

Yes I can try it [if I can find the time].

Any ideas/pointers to how one can easily right-align text in a
(mini-buffer) window?

It seems a bit difficult at present...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Any ideas/pointers to how one can easily right-align text in a
> (mini-buffer) window?

Note that it's not really the mini-buffer most of the time, but rather
the echo-area (they are very different).

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > Any ideas/pointers to how one can easily right-align text in a
> > (mini-buffer) window?
> 
> Note that it's not really the mini-buffer most of the time, but rather
> the echo-area (they are very different).
> 

Well, looking at the code the distinction is less clear IMO...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    Any ideas/pointers to how one can easily right-align text in a
    (mini-buffer) window?

You could calculate its width, subtract that from the total frame width,
and indent that much.

As Miles reminded us, this would be a kind of echo area
display--nothing to do with the minibuffer.  When the minibuffer is
active, this text will not appear.

The minibuffer is displayed as an ordinary buffer, displayed in a
buffer, so there is no special code for displaying it.  There is
special code for displaying the echo area.

Re: Suggestions for mode-line-format changes

[Mario Lang]

storm@cua.dk (Kim F. Storm) writes:

> Bill White <billw@wolfram.com> writes:
>
>> On Fri Aug 23 2002 at 11:33, Alan Shutko <ats@acm.org> said:
>> 
>> > Personally, I think that the global-mode-string information is more
>> > important to me than the modes, and this new change is exactly
>> > opposite my priorities.  I think that most people would probably
>> > agree with me.
>
> I guess most users will agree that knowing the time is
> important around lunch time and near the end of the day :-)
>
erc-track.el uses the global-mode-string to
indicate if a channel buffer not currently visible
had activity.  It is quite important for
this feature to be visible, and not scrolled out on the right side.

I agree that time isn't that important, but there are other things which can
be put into global-mode-string.  I dont think
it should be changed from it's current location.

OTOH, I always wanted something like global-mode-string
which only occurs once in a frame.  Currently, global-mode-string
is displayed as many times as windows are displayed in the current frame.
This is waste of space for most things using global-mode-string
(like time and the mail icon).

If we could come up with an equivalent which is only displayed
at one position in the frame, I'd like that.
(e.g. on the right side of the menu, or there somewhere).

P.S.: To be worthwhile, this feature would
need to work in X and -nw.


-- 
CYa,
  Mario

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Mario Lang <mlang@delysid.org> writes:

> erc-track.el uses the global-mode-string to
> indicate if a channel buffer not currently visible
> had activity.  It is quite important for
> this feature to be visible, and not scrolled out on the right side.
> 
> I agree that time isn't that important, but there are other things which can
> be put into global-mode-string.  I dont think
> it should be changed from it's current location.

There really seems to be different levels of importance of the things
people put into global-mode-string - some of which should be "very
visible" (e.g. battery status), some which should be "normally
visible" (e.g new mail, output available, important mode state), and
some which is just "nice to have" (e.g. time of day and system load).

Consequently, putting everything in a "global" state variable will
definitely not work well for all users...

Kai's idea of a fully configurable mode line format sounds nice, but
it will not work if we can only control where "global-mode-string" is
displayed in the mode-line; we need to be able to control the position
of each of the [current] elements of global-mode-string.

Maybe we could change the interpretation of global-mode-string [as the
last element in mode-line-format] in formatting the mode-line, so that
only the elements of global-mode-string which have not been
shown already are displayed for global-mode-string.

This could be done by maintaining a temporary list of the symbols used
so far to format the mode line and skip those symbols which have
already been displayed.  The means that you can insert
battery-mode-line-string explicitly in mode-line-format and not worry
about it being present in global-mode-string as well.


> 
> OTOH, I always wanted something like global-mode-string
> which only occurs once in a frame.  Currently, global-mode-string
> is displayed as many times as windows are displayed in the current frame.
> This is waste of space for most things using global-mode-string
> (like time and the mail icon).
> 
> If we could come up with an equivalent which is only displayed
> at one position in the frame, I'd like that.
> (e.g. on the right side of the menu, or there somewhere).
> 
> P.S.: To be worthwhile, this feature would
> need to work in X and -nw.

Displaying it in the (unused) echo area should work on all platform if
done correctly...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    erc-track.el uses the global-mode-string to
    indicate if a channel buffer not currently visible
    had activity.

Why use global-mode-string for this?  That doesn't seem
like the right method to use.  Why not put it in something
buffer-local?

Re: Suggestions for mode-line-format changes

[Kai Großjohann]

Alan Shutko <ats@acm.org> writes:

> Personally, I think that the global-mode-string information is more
> important to me than the modes, and this new change is exactly
> opposite my priorities.  I think that most people would probably agree
> with me.  Can we have a survey of some sort to decide whether to keep
> this change?  (Right now, I yanked the entire mode-line setup out of
> the old bindings.el, but that means I lose out on actual
> improvements.)

If it wasn't for the propertized strings in mode-line-format, it
would actually be easy for users to sort mode-line-format the way
they like: they just rearrange the existing elements the way they
like.

What do you think about making little variables mode-line-dash and
mode-line-space for them?

What do you think about doing a custom type for mode-line-format?  It
could be a list of variables whose names match the regexp "mode-line".

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    If it wasn't for the propertized strings in mode-line-format, it
    would actually be easy for users to sort mode-line-format the way
    they like: they just rearrange the existing elements the way they
    like.

    What do you think about making little variables mode-line-dash and
    mode-line-space for them?

That is a good idea--simple, painless, and probably useful.
Please do it.

    What do you think about doing a custom type for mode-line-format?  It
    could be a list of variables whose names match the regexp "mode-line".

That seems like a good idea too.  The custom type could be a series of
elements, each chosen from the set of suitable symbol names.

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    Personally, I think that the global-mode-string information is more
    important to me than the modes, and this new change is exactly
    opposite my priorities.  I think that most people would probably agree
    with me.  Can we have a survey of some sort to decide whether to keep
    this change?

This seems like the right sort of question for a poll.

mh-e 6.2 imminent

[Bill Wohler]

  I noticed that Emacs is in pre-release. We expect to release a beta of
  mh-e 6.2 at the end of the month. I assume that the pre-release means
  that only bug fixes are allowed, but if this isn't strictly the case,
  I was wondering if I'd be able to update mh-e when we're ready. It's a
  pretty big release (release notes enclosed), but is limited to just
  the mh-e files so it should be little or no risk to the rest of the
  project.


* Changes in mh-e 6.2

This is a major minor release which includes a lot of new features
including improved MIME handling, speedbar folder browsing, and
indexed searching. In this version, mh-e runs under XEmacs and
compiles clean under all supported platforms.

** New Features in mh-e 6.2

*** Speedbar

There is now support for the speedbar. Try "M-x speedbar" (closes SF
#503727). 

Press the middle mouse button on the `+' icons to open a folder,
middle mouse button on a folder name to open the folder. Folders with
unseen messages are shown in bold, so this is a handy way to browse
new messages that you have filed with procmail or slocal.

See the new customization variable `mh-large-folder,' which controls
when the speedbar asks for how many messages to scan when opening a
large folder.

*** Indexed search

Interoperability with swish, glimpse, and namazu has been added to
enable lightening-fast searches of your mail. If none of these are
present, grep is used. Try "F i (mh-index-search)".

For more information, read the documentation for the functions
`mh-swish-execute-search,' `mh-namazu-execute-search,' or
`mh-glimpse-execute-search' depending on your preferred indexing
program to see what kind of setup is needed to generate the index.
You'll first need to run "F i" or load "mh-thread" to read the
documentation.

*** Threading

Use "T t (mh-toggle-threads)" to view the threads in the folder. Use
it again to return to a non-threaded view.

*** Brief help

Use "? (mh-help)" and "X ? (mh-prefix-help)," where X is a prefix
character, for a brief synopsis in the minibuffer of frequently used
commands. In the MH-Letter or MH-Pick buffers, use "C-c ? (mh-help)"
(closes SF #493740).

*** Folder keymap shared by show buffer

You can now use the MH-Folder mode commands from the MH-Show buffer.
Because of this, the MH-Show buffer is now read-only (closes SF
#527946) and you now have to use "M (mh-modify)" to edit a message.
 
*** Better scanning

You no longer have to modify your scan format if your folders have
more than 9999 messages in them. If you've only modified your scan
format file to allow for the wider message numbers, consider removing
your modifications of `mh-scan.*-regexp' and `mh-cmd-note', set the
new customization variable `mh-adaptive-cmd-note' to t, and
`mh-scan-format-file' to its default (t).

You may still want the updated format files for running MH commands
outside of mh-e, but these changes will simplify your mh-e
configuration considerably.

*** X-Face

mh-e now displays the content of the X-Face header field in the From
field. When sending a message, an X-Face field is appended to the
header if it doesn't already exist and "~/.face" is present. See the
new customization variables `mh-show-use-xface' and `mh-x-face-file'
(closes SF #480770).

mh-e depends on the external x-face package found in
ftp://ftp.jpl.org/pub/elisp/ to do this.

*** Graphical smileys

Smiley's are now converted to cute little images. See the new
customization variable `mh-graphical-smileys-p.'

*** Text emphasis

ASCII formatting is now converted to the appropriate font. For
example, *bold* appears in bold, /italic/ appears in italic, etc. See
the new customization variables `mh-decode-mime' and
`mh-graphical-emphasis-p.'

*** Attachment handling

Inline attachments are now displayed. Regular attachments appear as
buttons in show buffer. Use "K TAB (mh-next-button)" or "K SHIFT-TAB
(mh-prev-button)" to cycle through these buttons. Use "K v
(mh-folder-toggle-mime-part)" to view, "K o
(mh-folder-save-mime-part)" to save one part or "M-x
mh-store-mime-parts" to save all parts, or "K i
(mh-folder-inline-mime-part)" to view the attachment inline.

See the new customization variable `mh-decode-mime' for additional
information. In additiona, see the new customization variable
`mh-store-mime-parts-default-directory.'

HTML documents can be viewed inline if Gnus v5.9 and w3 or w3m lisp
packages are present. Set the customization variable
`mm-text-html-renderer' accordingly (closes SF #453352).

*** Quoted-printable handling

Quoted-printable body parts are now decoded.

*** More choices for `mh-yank-from-start-of-msg'

Historically, if this variable was t, the entire message, with full
headers would be included and every line would begin with
`mh-ins-buf-prefix.' This usage is deprecated in favor of the setting
`supercite' below. The default has been changed to `attribution.' The
following symbols are now understood:

`body': yank the message minus the header.

`supercite': include the entire message, with full headers. This also
causes the invocation of `sc-cite-original' without the setting of
`mail-citation-hook', now deprecated practice.

`autosupercite': do as for `supercite' automatically when show buffer
matches the message being replied-to.

`attribution': yank the message minus the header and add a simple
attribution line at the top.

`autoattrib': do as for `attribution' automatically when show buffer
matches the message being replied-to.

There is a new customization variable called
`mh-extract-from-attribution-verb' which is used for attribution which
provides a method for setting a different language.

*** Use Gnus mml instead of mhn

When inserting attachments into a message draft, Gnus mml directives
are now used instead of mhn directives. One beneficial side-effect of
this is that attachments can now appear inline as well as separate.

The new customization variable `mh-compose-insertion' controls whether
Gnus or mhn is used to insert MIME message directives in messages
(default: 'gnus, if the mml library exists).

*** Content-Type now obtained automatically

The value of the Content-Type no longer needs to be entered by the
user.

*** Attachments automatically included upon send

You no longer have to run "C-c C-e (mh-edit-mhn)" before sending a
message with attachments--this is done automatically when you send the
message with "C-c C-c (mh-send-letter)". There is, however, a new key
binding "C-c C-m m (mh-mml-to-mime)" which is analogous to "C-c C-e
(mh-edit-mhn)".

** New Variables in mh-e 6.2

New customization variables not mentioned earlier include:

*** mh-tool-bar-reply-3-buttons

Non-nil means use three buttons for reply commands in tool-bar. If you
have room on your tool-bar because you are using a large font, you may
set this variable to expand the single reply button into three buttons
that won't lead to minibuffer prompt about who to reply to.

** Bug Fixes in mh-e 6.2

*** mh-delete-msg, mh-refile-msg, mh-undo

Mandrake Linux includes XEmacs initialization code that binds
`transient-mark-mode' which causes problems in mh-e. These problems
have been fixed (closes SF #541915).

*** mh-edit-again

This would sometimes yield a read-only buffer. This has been fixed
(closes SF #624283).

*** mh-next-undeleted-msg, mh-previous-undeleted-msg 

If there are no more undeleted messages the point remains at its
original position and a message is produced (closes SF #494304).

*** mh-refile-msg, mh-write-msg-to-file

These functions stomped on the variables that held the name of the
last file and folder respectively for the other function. This has
been fixed so that the last folder or file name is preserved (closes
SF #580772).

*** mh-region-to-sequence

If the region in MH-Folder was set with "C-x h (mark-whole-buffer)",
you couldn't perform operations on all of the messages as you would
expect. This has been fixed (closes SF #621632).

*** mh-reply

Performing an undo the first thing after replying would blank out the
entire draft. Now just the insertion of the yanked message is undone
leaving the header and signature intact for additional editing (closes
SF #623693).

*** mh-subject-thread-to-sequence

Make 'subject sequence a real one, exported to MH. This means you can,
for example, mh-forward it. But it also shows up with a mark in the
scan output (closes SF #489445).



--
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: mh-e 6.2 imminent

[Kim F. Storm]

Bill Wohler <wohler@newt.com> writes:

>   I noticed that Emacs is in pre-release.

Release 21.3 is a maintenance release from the 21.1 release branch.

Release 21.4 is to be released from the CVS trunk which is still not
in feature freeze, so currently it would be ok to update mh-e on the
trunk.

>   I was wondering if I'd be able to update mh-e when we're ready.

It all depends on when that will be -- and when we decide to feature
freeze 21.4 (it has been suggested to do so recently, but I don't
think we agreed to do that any time soon).

> * Changes in mh-e 6.2
> 
> This is a major minor release

A major minor release :-) 


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: mh-e 6.2 imminent

[Juanma Barranquero]

On 21 Oct 2002 12:04:48 +0200, storm@cua.dk (Kim F. Storm) wrote:

> It all depends on when that will be -- and when we decide to feature
> freeze 21.4 (it has been suggested to do so recently, but I don't
> think we agreed to do that any time soon).

It'd be good to decide some sort of (approximate) timeline, and also to
reach a decision about the numbering scheme (AFAIR, there was much
discussion but no definitive decision, but I can be wrong).


                                                           /L/e/k/t/u

Re: mh-e 6.2 imminent

[Richard Stallman]

      I noticed that Emacs is in pre-release. We expect to release a beta of
      mh-e 6.2 at the end of the month. I assume that the pre-release means
      that only bug fixes are allowed, but if this isn't strictly the case,

You can update mh-e fully whenever you like.  The current pretest is
irrelevant to this.

Re: mh-e 6.2 imminent

[Bill Wohler]

Kim F. Storm <storm@cua.dk> wrote:

> Release 21.3 is a maintenance release from the 21.1 release branch.
> 
> Release 21.4 is to be released from the CVS trunk which is still not
> in feature freeze, so currently it would be ok to update mh-e on the
> trunk.

  Ah, that explains a lot.

> > This is a major minor release
> 
> A major minor release :-) 

  So you noticed ;-). In addition to all of the new features, we also
  took pains to get mh-e to compile cleanly. It now also passes checkdoc
  cleanly, except for some old boolean variables that don't end in
  -flag. We'd like to fix those up before committing to Emacs and reduce
  the user exposure to the change, and obviously bump the major version
  to reflect that change (7.0).

Richard Stallman <rms@gnu.org> wrote:

> You can update mh-e fully whenever you like.

  Thank you. Will do. Expect a version 7.0 that will be more robust than
  6.2 would have been by the end of November or so.

--
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: mh-e 6.2 imminent

[Stefan Monnier]

>   So you noticed ;-). In addition to all of the new features, we also
>   took pains to get mh-e to compile cleanly. It now also passes checkdoc
>   cleanly, except for some old boolean variables that don't end in
>   -flag. We'd like to fix those up before committing to Emacs and reduce
>   the user exposure to the change, and obviously bump the major version
>   to reflect that change (7.0).

Don't take checkdoc too literally.  I for one strongly dislike the
idea of using -flag postfixes, as I've already mentioned somewhere,
among other things because it's not a widely followed convention
and because many boolean variables turn into 3-way (or more) variables
over time.
It's more important to keep the old names than to try to follow some
rarely followed convention.


	Stefan

Re: mh-e 6.2 imminent

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> Don't take checkdoc too literally.  I for one strongly dislike the
> idea of using -flag postfixes, as I've already mentioned somewhere,
> among other things because it's not a widely followed convention
> and because many boolean variables turn into 3-way (or more) variables
> over time.

I've never heard of this `convention,' and indeed, it sounds kind of
dumb -- a `-flag' suffix doesn't really add any useful information
(if you know the _meaning_ of a variable, then you already know whether
it's boolean or not, and if you don't know the meaning, well, then it
hardly helps you to know that it's boolean!).

Why on earth does checkdoc try to enforce this?  Can we take that out?

[I have my own agendas of course -- I'd like to make checkdoc complain
if people use a `-p' suffix for variables, or a `-face' suffix for
faces...]

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: mh-e 6.2 imminent

[Mark D. Baushke]

Miles Bader <miles@lsi.nec.co.jp> writes:

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > Don't take checkdoc too literally.  I for one strongly dislike the
> > idea of using -flag postfixes, as I've already mentioned somewhere,
> > among other things because it's not a widely followed convention
> > and because many boolean variables turn into 3-way (or more) variables
> > over time.
>
> I've never heard of this `convention,' and indeed, it sounds kind of
> dumb -- a `-flag' suffix doesn't really add any useful information
> (if you know the _meaning_ of a variable, then you already know whether
> it's boolean or not, and if you don't know the meaning, well, then it
> hardly helps you to know that it's boolean!).
>
> Why on earth does checkdoc try to enforce this?  Can we take that out?

I would certainly not complain about a configuration option to turn off
the `-flag' suffix convention.

However, at least a few of the variables that are going to be renamed
have what I consider to be a worse problem. They end with a `-p' suffix
which I really dislike for variables to have.

User defcustom variables:

   mh-bury-show-buffer       -> mh-bury-show-buffer-flag
   mh-clean-message-header   -> mh-clean-message-header-flag
   mh-do-not-confirm         -> mh-do-not-confirm-flag
   mh-insert-x-mailer-p      -> mh-insert-x-mailer-flag
   mh-recenter-summary-p     -> mh-recenter-summary-flag
   mh-reply-show-message-p   -> mh-reply-show-message-flag
   mh-show-use-goto-addr     -> mh-show-use-goto-addr-flag

Internal variables to be renamed:

   save-modification-flag-p  -> mh-save-modification-flag
   mh-page-to-next-msg-p     -> mh-page-to-next-msg-flag
   mh-mhn-compose-insert-p   -> mh-mhn-compose-insert-flag
   mh-nmh-p                  -> mh-nmh-flag

> [I have my own agendas of course -- I'd like to make checkdoc complain
> if people use a `-p' suffix for variables, or a `-face' suffix for
> faces...]

I would support such changes to checkdoc for the `-p' suffix.

Would you care to share the argument for the `-face' suffix?

I suspect that mh-e has some of these and if we are going to do
a renaming, we may as well try to accommodate all such changes
now rather than later.

Feel free to add comments to the SourceForge.Net bugid #627015

https://sourceforge.net/tracker/?func=detail&atid=113357&aid=627015&group_id=13357

on this topic.

        Thanks,
        -- Mark

Re: mh-e 6.2 imminent

[Miles Bader]

"Mark D. Baushke" <mdb@gnu.org> writes:
> I would support such changes to checkdoc for the `-p' suffix.
> 
> Would you care to share the argument for the `-face' suffix?

Faces have their very own namespace, so if a face is called `foo-face',
the suffix is completely redundant and tells you nothing.  It's as if
you called every variable `foo-variable'.

[note that I'm not talking about _variables_ containing faces
(symbols), but the faces themselves]

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

checkdoc (was: mh-e 6.2 imminent)

[Stefan Monnier]

> I've never heard of this `convention,' and indeed, it sounds kind of
> dumb -- a `-flag' suffix doesn't really add any useful information
> (if you know the _meaning_ of a variable, then you already know whether
> it's boolean or not, and if you don't know the meaning, well, then it
> hardly helps you to know that it's boolean!).

It's sadly even mentioned in the elisp doc :-(

	work/emacs-0% grep -C flag lispref/tips.texi 
	@item
	If a user option variable records a true-or-false condition, give it a
	name that ends in @samp{-flag}.
	[...]

Luckily it's rarely folowed.

> Why on earth does checkdoc try to enforce this?  Can we take that out?

I'd be happy to.

> [I have my own agendas of course -- I'd like to make checkdoc complain
> if people use a `-p' suffix for variables, or a `-face' suffix for
> faces...]

Agreed for the `-p'.  For `-face', I'm still not sure either way.


	Stefan

Re: checkdoc (was: mh-e 6.2 imminent)

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

re. removing check for -flag, count me in!

> 
> > [I have my own agendas of course -- I'd like to make checkdoc complain
> > if people use a `-p' suffix for variables, or a `-face' suffix for
> > faces...]
> 
> Agreed for the `-p'.  For `-face', I'm still not sure either way.

Well, I agree with Miles that formally, the -face suffix is redundant
since faces have their own namespace.

However, when you want to customize a group, I think having the face
suffix makes a big difference to the user.  

E.g. try customize-group on ido; there you will see the following
headings to customize ido's faces:

	Ido First Match Face: (sample) [Show Face]
	
	Ido Only Match Face: (sample) [Show Face]
	
	Ido Subdir Face: (sample) [Show Face]
	
	Ido Indicator Face: (sample) [Show Face]

which I definitely prefer to 

	Ido First Match: (sample) [Show Face]
	
	Ido Only Match: (sample) [Show Face]
	
	Ido Subdir: (sample) [Show Face]
	
	Ido Indicator: (sample) [Show Face]

Also, for code maintenance, I personally think having the -face suffix
on faces makes the code easier to read!

So in my option -face suffix is preferable, and I would actually
argue in favour of _recommending_ using it (which most lisp
packages seem to do anyway)!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: checkdoc (was: mh-e 6.2 imminent)

[Miles Bader]

On Thu, Oct 24, 2002 at 01:13:11PM +0200, Kim F. Storm wrote:
> However, when you want to customize a group, I think having the face
> suffix makes a big difference to the user.  
> 
> E.g. try customize-group on ido; there you will see the following
> headings to customize ido's faces:
> 
> 	Ido First Match Face: (sample) [Show Face]
> 
> which I definitely prefer to 
> 
> 	Ido First Match: (sample) [Show Face]

Have you tried it with a non `-face' face?  Customize-face will automatically
put in a `face:' after the name to make it more clear.

> So in my option -face suffix is preferable, and I would actually
> argue in favour of _recommending_ using it (which most lisp
> packages seem to do anyway)!

No, it's probably more about half and half.  In particular, the `base' faces
(those defined in faces.el) don't use it.

As far as I can figure, the use of `-face' results from people confusing
faces with variables that point to faces; it seems that the latter used to
be more common than they are now (e.g. the variables and faces used by
font-lock).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: checkdoc (was: mh-e 6.2 imminent)

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Have you tried it with a non `-face' face?  Customize-face will automatically
> put in a `face:' after the name to make it more clear.

Obviuosly not :-)

> 
> > So in my option -face suffix is preferable, and I would actually
> > argue in favour of _recommending_ using it (which most lisp
> > packages seem to do anyway)!
> 
> No, it's probably more about half and half.  In particular, the `base' faces
> (those defined in faces.el) don't use it.

Gnus/message/customize/widget/diff/ediff/font-lock all use the -face suffix.
Only the basic faces seem not to use the -face suffix.

> 
> As far as I can figure, the use of `-face' results from people confusing
> faces with variables that point to faces; it seems that the latter used to
> be more common than they are now (e.g. the variables and faces used by
> font-lock).

True.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: checkdoc (was: mh-e 6.2 imminent)

[Miles Bader]

On Thu, Oct 24, 2002 at 06:15:42PM +0200, Kim F. Storm wrote:
> Gnus/message/customize/widget/diff/ediff/font-lock all use the -face suffix.
> Only the basic faces seem not to use the -face suffix.

A quick grep shows:  out of 498 defface's 312 use `-face', so 3/5.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: checkdoc (was: mh-e 6.2 imminent)

[Richard Stallman]

    Gnus/message/customize/widget/diff/ediff/font-lock all use the -face suffix.
    Only the basic faces seem not to use the -face suffix.

Perhaps we should rename the others for greater consistency.

Re: checkdoc (was: mh-e 6.2 imminent)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Gnus/message/customize/widget/diff/ediff/font-lock all use the -face suffix.
>     Only the basic faces seem not to use the -face suffix.
> 
> Perhaps we should rename the others for greater consistency.

Given Miles' statistics, that's +300 face names to be changed!

Since some (many?) of those are user customizeable, changing their
name would be problematic -- so I suggest leaving things as they are!


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: checkdoc (was: mh-e 6.2 imminent)

[Richard Stallman]

    Given Miles' statistics, that's +300 face names to be changed!

    Since some (many?) of those are user customizeable, changing their
    name would be problematic -- so I suggest leaving things as they are!

We could make an alias mechanism for faces.

Re: checkdoc (was: mh-e 6.2 imminent)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Given Miles' statistics, that's +300 face names to be changed!
> 
>     Since some (many?) of those are user customizeable, changing their
>     name would be problematic -- so I suggest leaving things as they are!
> 
> We could make an alias mechanism for faces.

Yes, but I still feel we could spend our time better on other things
than renaming and creating aliases for 300+ faces -- if the _users_
will never see the difference (as Miles pointed out, customize adds
"Face" to the face name if its missing...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: checkdoc (was: mh-e 6.2 imminent)

[Richard Stallman]

    Yes, but I still feel we could spend our time better on other things
    than renaming and creating aliases for 300+ faces -- if the _users_
    will never see the difference (as Miles pointed out, customize adds
    "Face" to the face name if its missing...

You may be right.  But we can still document a convention for this,
for the future.

One interesting question is, are there cases where ending a face name
with -face is actually beneficial?  What do people think?

Re: checkdoc (was: mh-e 6.2 imminent)

[Henrik Enberg]

Richard Stallman <rms@gnu.org> writes:

> One interesting question is, are there cases where ending a face name
> with -face is actually beneficial?  What do people think?

I think it's pretty natural to end them with -face.  For one thing, it
makes it easy to look up with apropos.  And take something like
`font-lock-keyword-face', what would be a better name?  the current
name is self-documenting.

-- 
Booting... /vmemacs.el

Re: checkdoc (was: mh-e 6.2 imminent)

[Miles Bader]

On Mon, Oct 28, 2002 at 08:38:10PM +0100, Henrik Enberg wrote:
> I think it's pretty natural to end them with -face.  And take something
> like `font-lock-keyword-face', what would be a better name?

`font-lock-keyword'

[e.g., (setq font-lock-keyword-face 'font-lock-keyword) ]

> the current name is self-documenting.

If we ended every variable in `-variable', they would all be "self
documenting" too.

The question is whether this is useful property, more than it is an annoying
one (and I think you'll agree that calling every variable foo-variable would
be really annoying!).

When I look at source code [I just did this using grep] that refers to
constant face names, which is the main place where this matters, I see
things like:

   (defface foo-face ...)

   (defvar blah-blah-face 'foo-face)

   (put-text-property X Y 'face 'foo-face)

   (set-face-foreground 'foo-face "...")

   (copy-face 'foo-face)

   (let ((face (make-face 'foo-face))) ...)

   (cons 'foo-face list-of-faces)

Note that all these cases, the `-face' in the face name doesn't help at all,
because the variable/function/macro/property two which the constant face is
being assigned/passed almost always _explicitly_ makes it clear that a face
is being operated upon.  In the `-face' suffix seems redundant, because it's
entirely obvious -- even to someone who doesn't understand what the source
code does! -- that it's a face being manipulated.

I find the above situation pretty typical.

The main exception, as far as I can see, is font-lock specifications, which
generally look like indecipherable gobs of hair, so the face names tend to
stand out as the one thing who's meaning is obvious.

So to summarize, I don't think such face names really help at all, they just
make the source code ugly.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: checkdoc (was: mh-e 6.2 imminent)

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Mon, Oct 28, 2002 at 08:38:10PM +0100, Henrik Enberg wrote:
> > I think it's pretty natural to end them with -face.  And take something
> > like `font-lock-keyword-face', what would be a better name?
> 
> `font-lock-keyword'
> 
> [e.g., (setq font-lock-keyword-face 'font-lock-keyword) ]
> 
> > the current name is self-documenting.
> 
> If we ended every variable in `-variable', they would all be "self
> documenting" too.
> 
> The question is whether this is useful property, more than it is an annoying
> one (and I think you'll agree that calling every variable foo-variable would
> be really annoying!).

Of course we don't need that .... as long as we call the faces -face :-)

> 
> When I look at source code [I just did this using grep] that refers to
> constant face names, which is the main place where this matters, I see
> things like:
> 
>    (defface foo-face ...)
> 
>    (defvar blah-blah-face 'foo-face)
> 
>    (put-text-property X Y 'face 'foo-face)
> 
>    (set-face-foreground 'foo-face "...")
> 
>    (copy-face 'foo-face)
> 
>    (let ((face (make-face 'foo-face))) ...)
> 
>    (cons 'foo-face list-of-faces)
> 
> Note that all these cases, the `-face' in the face name doesn't help at all,

.. except if you need to grep for all uses of a given face.  I find
it more precise to grep for FOO-face rather than FOO -- which for some
FOO gives a lot of false matches.

Try to find all uses of the region and mouse faces...  I bet that you
get numerous false hits that you wouldn't have got had they been named
region-face and mouse-face.  

> because the variable/function/macro/property two which the constant face is
> being assigned/passed almost always _explicitly_ makes it clear that a face
> is being operated upon.  In the `-face' suffix seems redundant, because it's
> entirely obvious -- even to someone who doesn't understand what the source
> code does! -- that it's a face being manipulated.
> 
> I find the above situation pretty typical.

And I like all of them better than the non -face alternatives!

> 
> The main exception, as far as I can see, is font-lock specifications, which
> generally look like indecipherable gobs of hair, so the face names tend to
> stand out as the one thing who's meaning is obvious.

I fully agree re. font-lock!!

> 
> So to summarize, I don't think such face names really help at all, they just
> make the source code ugly.

Well, FWIW, I disagree.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: checkdoc (was: mh-e 6.2 imminent)

[Miles Bader]

On Tue, Oct 29, 2002 at 12:19:13AM +0100, Kim F. Storm wrote:
> Try to find all uses of the region and mouse faces...  I bet that you
> get numerous false hits that you wouldn't have got had they been named
> region-face and mouse-face.  

Because of the property I've already noted -- that uses of constant faces
almost always occur in contexts where the use of a face is _explicit_,
e.g. accompanying a variable or function called `...-face' -- I can do this:

  grep "face.*'region" ...

which in fact works quite well.

One way you can test this is to pick some existing face called `foo-face',
and grep for both "foo-face" and "face.*foo" in the sources.  It's best to
pick a face that _doesn't_ have an identically-named variable, because
otherwise you tend to get lots of false hits in the `foo-face' case

[this is a problem, incidentally, with faces like `foo-face' -- code such as
font-lock tends to be even more confusing because there are _identical_
symbols being used for both variables and faces, in ways that are not that
easy to distinguish at first glance; I think it would actually be _more_
clear if only the variables were called `foo-face']

Here's an example:

First using the `-face' suffix:

   grep -nH "gnus-cite-attribution-face" lisp/gnus/*.el
   lisp/gnus/gnus-cite.el:126:(defface gnus-cite-attribution-face '((t
   lisp/gnus/gnus-cite.el:130:(defcustom gnus-cite-attribution-face 'gnus-cite-attribution-face
   lisp/gnus/gnus-cite.el:317:corresponding citation merged with `gnus-cite-attribution-face'.
   lisp/gnus/gnus-cite.el:367:	(gnus-cite-add-face number skip gnus-cite-attribution-face))
   lisp/gnus/gnus-cite.el:375:	(gnus-cite-add-face number skip gnus-cite-attribution-face)))))

Now without it:

   grep -nH "face.*gnus-cite-attribution" lisp/gnus/*.el
   lisp/gnus/gnus-cite.el:126:(defface gnus-cite-attribution-face '((t
   lisp/gnus/gnus-cite.el:130:(defcustom gnus-cite-attribution-face 'gnus-cite-attribution-face
   lisp/gnus/gnus-cite.el:367:	(gnus-cite-add-face number skip gnus-cite-attribution-face))
   lisp/gnus/gnus-cite.el:375:	(gnus-cite-add-face number skip gnus-cite-attribution-face)))))

Note that the second catches all the same cases except a mention in a
doc-string.

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: checkdoc (was: mh-e 6.2 imminent)

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Tue, Oct 29, 2002 at 12:19:13AM +0100, Kim F. Storm wrote:
> > Try to find all uses of the region and mouse faces...  I bet that you
> > get numerous false hits that you wouldn't have got had they been named
> > region-face and mouse-face.  
> 
> Because of the property I've already noted -- that uses of constant faces
> almost always occur in contexts where the use of a face is _explicit_,
> e.g. accompanying a variable or function called `...-face' -- I can do this:
> 
>   grep "face.*'region" ...
> 
> which in fact works quite well.

But fails if face and region are on different lines...

> 
> One way you can test this is to pick some existing face called `foo-face',
> and grep for both "foo-face" and "face.*foo" in the sources.  It's best to
> pick a face that _doesn't_ have an identically-named variable, because
> otherwise you tend to get lots of false hits in the `foo-face' case

I think it is a matter of taste whether those identically named
variables are false hits.

> 
> [this is a problem, incidentally, with faces like `foo-face' -- code such as
> font-lock tends to be even more confusing because there are _identical_
> symbols being used for both variables and faces, in ways that are not that
> easy to distinguish at first glance; I think it would actually be _more_
> clear if only the variables were called `foo-face']
> 
> Here's an example:
> 
> First using the `-face' suffix:
> 
>    grep -nH "gnus-cite-attribution-face" lisp/gnus/*.el
>    lisp/gnus/gnus-cite.el:126:(defface gnus-cite-attribution-face '((t
>    lisp/gnus/gnus-cite.el:130:(defcustom gnus-cite-attribution-face 'gnus-cite-attribution-face
>    lisp/gnus/gnus-cite.el:317:corresponding citation merged with `gnus-cite-attribution-face'.
>    lisp/gnus/gnus-cite.el:367:	(gnus-cite-add-face number skip gnus-cite-attribution-face))
>    lisp/gnus/gnus-cite.el:375:	(gnus-cite-add-face number skip gnus-cite-attribution-face)))))
> 
> Now without it:
> 
>    grep -nH "face.*gnus-cite-attribution" lisp/gnus/*.el
>    lisp/gnus/gnus-cite.el:126:(defface gnus-cite-attribution-face '((t
>    lisp/gnus/gnus-cite.el:130:(defcustom gnus-cite-attribution-face 'gnus-cite-attribution-face
>    lisp/gnus/gnus-cite.el:367:	(gnus-cite-add-face number skip gnus-cite-attribution-face))
>    lisp/gnus/gnus-cite.el:375:	(gnus-cite-add-face number skip gnus-cite-attribution-face)))))
> 
> Note that the second catches all the same cases except a mention in a
> doc-string.

I don't have problems separating those in general -- a face is usually
quoted, a variable is not.


I think somebody else should express their opinions -- as you and I
obviously cannot agree on this (IMHO non-)issue.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: checkdoc (was: mh-e 6.2 imminent)

[Henrik Enberg]

Miles Bader <miles@gnu.org> writes:

> On Mon, Oct 28, 2002 at 08:38:10PM +0100, Henrik Enberg wrote:
>> I think it's pretty natural to end them with -face.  And take something
>> like `font-lock-keyword-face', what would be a better name?
>
> `font-lock-keyword'
>
> [e.g., (setq font-lock-keyword-face 'font-lock-keyword) ]
>
>> the current name is self-documenting.
>
> If we ended every variable in `-variable', they would all be "self
> documenting" too.

No, that would just be silly.  There is no need to to over-consistent.

> The question is whether this is useful property, more than it is an annoying
> one (and I think you'll agree that calling every variable foo-variable would
> be really annoying!).
>
> When I look at source code [I just did this using grep] that refers to
> constant face names, which is the main place where this matters, I see
> things like:
>
>    (defface foo-face ...)

[...]

>    (cons 'foo-face list-of-faces)
>
> Note that all these cases, the `-face' in the face name doesn't help at all,
> because the variable/function/macro/property two which the constant face is
> being assigned/passed almost always _explicitly_ makes it clear that a face
> is being operated upon.  In the `-face' suffix seems redundant, because it's
> entirely obvious -- even to someone who doesn't understand what the source
> code does! -- that it's a face being manipulated.

It _is_ pretty redundant when writing code, but from a user perspective,
it make them easier to find,  I think a typical user is more likely to
use ``C-h v'' and apropos than to grep the source code.

-- 
Booting... /vmemacs.el

Re: checkdoc (was: mh-e 6.2 imminent)

[Stefan Monnier]

> The main exception, as far as I can see, is font-lock specifications, which
> generally look like indecipherable gobs of hair, so the face names tend to
> stand out as the one thing who's meaning is obvious.

Most font-lock specifications don't use face names but variable names.
So it's actually not an exception,


	Stefan

Re: checkdoc (was: mh-e 6.2 imminent)

[Kim F. Storm]

Henrik Enberg <henrik@enberg.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > One interesting question is, are there cases where ending a face name
> > with -face is actually beneficial?  What do people think?
> 
> I think it's pretty natural to end them with -face.  For one thing, it
> makes it easy to look up with apropos.  And take something like
> `font-lock-keyword-face', what would be a better name?  the current
> name is self-documenting.

In general, I prefer the -face suffix for the same reasons as Henrik.

The only place where I really don't like the -face suffix is in the
output from M-x list-faces-display.

BTW, that list doesn't use the same names as used by Customize -- which
replaces dashes by spaces and adds "Face" if missing.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: checkdoc (was: mh-e 6.2 imminent)

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> BTW, that list doesn't use the same names as used by Customize -- which
> replaces dashes by spaces and adds "Face" if missing.

[though the added "face" is actually visually distinct -- it's in a
different font, and is lower case (all words in the `pretty' names
generated by customize are capitalized).  In other words, the point is
not to make it look like `face' is part of the name, but simply to make
clear that it's a face being customized.]

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: checkdoc (was: mh-e 6.2 imminent)

[Richard Stallman]

    The only place where I really don't like the -face suffix is in the
    output from M-x list-faces-display.

    BTW, that list doesn't use the same names as used by Customize -- which
    replaces dashes by spaces and adds "Face" if missing.

We could make it change dashes to spaces and *remove* "Face" at the
end.  However, that might cause confusion if programmers use it
to find the actual Lisp names of faces they want to use.

Re: checkdoc (was: mh-e 6.2 imminent)

[Richard Stallman]

    I think it's pretty natural to end them with -face.  For one thing, it
    makes it easy to look up with apropos.  And take something like
    `font-lock-keyword-face', what would be a better name?  the current
    name is self-documenting.

But we don't want to end all of them with `face'.  It would be a pain
in the neck if faces like `italic' and `underline' ended that way.

Have you actually used this to look them up with apropos?

Re: checkdoc (was: mh-e 6.2 imminent)

[Miles Bader]

On Tue, Oct 29, 2002 at 06:28:58AM -0500, Richard Stallman wrote:
> Have you actually used this to look them up with apropos?

You know, if searching for faces is truly a problem (it isn't for me -- there
are so few of them that I usually just use `list-faces-display'), we could
add an `apropos-face' command...  [Perhaps it makes sense to do that
regardless, since it _is_ a separate namespace, and adding specialized
apropos commands isn't hard.]

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: checkdoc (was: mh-e 6.2 imminent)

[Henrik Enberg]

Richard Stallman <rms@gnu.org> writes:

>     I think it's pretty natural to end them with -face.  For one thing, it
>     makes it easy to look up with apropos.  And take something like
>     `font-lock-keyword-face', what would be a better name?  the current
>     name is self-documenting.
>
> But we don't want to end all of them with `face'.  It would be a pain
> in the neck if faces like `italic' and `underline' ended that way.

Those kinds on names are pretty common when it comes to
typography, but names like font-lock-keyword or diff-added would be
less clear.

> Have you actually used this to look them up with apropos?

Occasionally, when I was a newbie, though I didn't know about
list-faces-display then.  I think Miles idea about an appropos-face
command sounds useful. 

-- 
Booting... /vmemacs.el

Re: checkdoc (was: mh-e 6.2 imminent)

[Miles Bader]

Henrik Enberg <henrik@enberg.org> writes:
> > But we don't want to end all of them with `face'.  It would be a pain
> > in the neck if faces like `italic' and `underline' ended that way.
> 
> Those kinds on names are pretty common when it comes to
> typography, but names like font-lock-keyword or diff-added would be
> less clear.

Well, less clear when you mention them out-of-context, but the point
I've been trying to make is that face names are almost always used in a
context where their meaning is pretty obvious.  [In other words, don't
just say `less clear,' say `less clear in such-and-such a circumstance.']

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: mh-e 6.2 imminent

[Richard Stallman]

    I've never heard of this `convention,' and indeed, it sounds kind of
    dumb -- a `-flag' suffix doesn't really add any useful information
    (if you know the _meaning_ of a variable, then you already know whether
    it's boolean or not, and if you don't know the meaning, well, then it
    hardly helps you to know that it's boolean!).

The idea of this convention is to make it easier to figure out the
precise meaning of the variable from its name.  It would be a useful
convention if it were followed more consistently.

Re: mh-e 6.2 imminent

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> The idea of this convention is to make it easier to figure out the
> precise meaning of the variable from its name.  It would be a useful
> convention if it were followed more consistently.

My argument is that adding `-flag' rarely does make it any easier to
figure out the meaning, and it makes code much uglier.

Compare:

  (setq use-some-behavior t)
  (if use-some-behavior x y)

with:

  (setq use-some-behavior-flag t)
  (if use-some-behavior-flag x y)

In situations like this, `-flag' just screams `redundant!' (it feels a
bit like code that says `if (var == true)').

I don't know if this is an inherent property of boolean variables (as
opposed to a convention like using `-function' with variables that
should hold a function, which does seem genuinely useful), or just
something that results from familiarity with existing convention, but it
seems quite obviously true to me.

One theory I have is that boolean variables are usually named as if
they were verbs, e.g. `do-something', which implicitly tags them as
being boolean (and which is why `-flag' seems redundant).

[Other variable are usually nouns, and what adding `-flag' does is try
to convert the verb-forms to noun-forms -- but programmers are already
used to the verb forms from long usage, so this apparent improvement
in consistency actually just confuses things.]

-Miles
-- 
Run away!  Run away!

Re: mh-e 6.2 imminent

[Richard Stallman]

    One theory I have is that boolean variables are usually named as if
    they were verbs, e.g. `do-something', which implicitly tags them as
    being boolean (and which is why `-flag' seems redundant).

This is an interesting line of thought.  It could be that the suffix
-flag is useful for some kinds of names and not for others, depending
on this grammatical criterion.

For instance, consider `file-precious-flag': there, `-flag' seems
to be useful, but `file-precious' does not have a verb.
Perhaps that is why `-flag' is useful there.

Re: mh-e 6.2 imminent

[Francesco Potorti`]

> dumb -- a `-flag' suffix doesn't really add any useful information

I disagree.  It makes it immediately clear that it is a boolean variable
or such.  Very useful, in my opinion.

Re: mh-e 6.2 imminent

[Peter S Galbraith]

[I'm cutting down the CC's.  These people are surely subscribed anyway.]

Francesco Potorti` <pot@gnu.org> wrote:

> > dumb -- a `-flag' suffix doesn't really add any useful information
> 
> I disagree.  It makes it immediately clear that it is a boolean variable
> or such.  Very useful, in my opinion.

We've made the transition to using -flag in mh-e since this thread
started.  But I'll admit to being worried that some-variable-flag will
eventually need to hold more than nil or t, and we'll be testing for
some symbol.  And then the -flag name won't hold true and we'll have to
rename it and break people's .emacs file.

Peter

Re: mh-e 6.2 imminent

[Richard Stallman]

      And then the -flag name won't hold true and we'll have to
    rename it and break people's .emacs file.

Now that we have aliases for variables, you can rename a variable and
make the old name an alias.  So the .emacs files will not will
actually break.

Nonetheless, the need to change the name is somewhat undesirable.

Re: mh-e 6.2 imminent

[Francesco Potorti`]

>We've made the transition to using -flag in mh-e since this thread
>started.  But I'll admit to being worried that some-variable-flag will
>eventually need to hold more than nil or t, and we'll be testing for
>some symbol.

Well, a flag can have different colours :-)

Re: etags -f /dev/stdout enhancement request

[Francesco Potorti`]

Lyndon, thank for your bug report.

>etags treats "-f -" as a special case in that the pathname of the
>source file is not made relative to the location of the tags file.
>Specifying "-f /dev/stdout" defeats this check, resulting in bogus
>source file pathnames in the tags file.

Yes, etags creates relative file names in tag files if the names of the
tagged files on the command line are relative names.  Otherwise it
creates absolute file names.

When it creates relative file names, they are made relative to the
directory of the tag file, which does not make sense for /dev/stdout.

Lyndon proposes to treat /dev/stdout the way it is done with "-", that
is, making file names relative to the current directory.  I see other
possibilities, on which I ask for advice:

1. when the tag file is under the /dev directory, use the current
   directory rather than /dev for creating relative file names
2. do the above only for /dev/stdout (as proposed by Lyndon)
3. when the tag file is under the /dev directory, use the root directory
   rather than /dev, which means to always create absolute file names

Re: etags -f /dev/stdout enhancement request

[Lyndon Nerenberg]

>1. when the tag file is under the /dev directory, use the current
>   directory rather than /dev for creating relative file names

I think this is a better solution (e.g. /dev/fd/1).

--lyndon

Re: mh-e 6.2 imminent

[Miles Bader]

Francesco Potorti` <pot@gnu.org> writes:
> > dumb -- a `-flag' suffix doesn't really add any useful information
> 
> I disagree.  It makes it immediately clear that it is a boolean variable
> or such.  Very useful, in my opinion.

Please see my reply to Richard about this.

Thanks,

-Miles
-- 
Fast, small, soon; pick any 2.

Re: Emacs crash in X

[Richard Stallman]

    I move the new frame to a different workspace (it is important
    to move it to a different workspace as moving it to a
    different viewport in window managers that support both

I use Sawfish; does it have any analogous feature?
If so, can someone tell me how to do this with Sawfish?

You can also debug this yourself.  Run Emacs under GDB then
evaluate (x-synchronize t), then make it fail.  That way you
will get a useful backtrace.  Please read etc/DEBUG for more
suggestions for how to debug this.

S-backspace

[Alex Schroeder]

In the new CVS, <S-backspace> runs the command kill-whole-line.
I'm hitting it about twice a day by accident, confusing me.
Can we reconsider this recent keybinding addition?

Alex
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Re: S-backspace

[Miles Bader]

On Mon, May 26, 2003 at 01:01:57AM +0200, Alex Schroeder wrote:
> In the new CVS, <S-backspace> runs the command kill-whole-line.
> I'm hitting it about twice a day by accident, confusing me.
> Can we reconsider this recent keybinding addition?

Yeah, I also find shift is somewhat easier to hit accidentally than other
modifiers, presumably because it usually has no effect, so my fingers have
gotten into the habit of not releasing it very quickly after entering shifted
letter.  So for instance if I accidentally enter `M' when I meant to enter
`m', I tend to hit the DEL key while my brain is still processing the
`release shift' concept, so end up hitting S-DEL about 50% of the time...

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: S-backspace

[Luc Teirlinck]

Miles Bader wrote:
   
   On Mon, May 26, 2003 at 01:01:57AM +0200, Alex Schroeder wrote:
   > In the new CVS, <S-backspace> runs the command kill-whole-line.
   > I'm hitting it about twice a day by accident, confusing me.
   > Can we reconsider this recent keybinding addition?

   Yeah, I also find shift is somewhat easier to hit accidentally than
   other modifiers, presumably because it usually has no effect, so my
   fingers have gotten into the habit of not releasing it very quickly
   after entering shifted letter.  So for instance if I accidentally
   enter `M' when I meant to enter `m', I tend to hit the DEL key
   while my brain is still processing the `release shift' concept, so
   end up hitting S-DEL about 50% of the time...

What about <M-S-backspace>.  Given your habits, that might still give
you problems when trying to kill an entirely capitalized word backward
with <M-backspace>, but that would seem to be a less frequent
situation.  I guess that C-S combinations might be indistinguishable
from plain C- on certain operating systems?

Sincerely,

Luc.

Re: S-backspace

[Luc Teirlinck]

>From my earlier message:

   I found the answer to my own question in the Elisp manual: only
   possible when using X terminals or other special terminals.  So we can
   not use C-S.

But I forgot, that, of course, the same already holds for
<C-backspace> to begin with.

Sincerely,

Luc.

Re: S-backspace

[Luc Teirlinck]

>From my earlier message:

   But I forgot, that, of course, the same already holds for
   <C-backspace> to begin with.

I meant <S-backspace>, of course, which when I use emacs -nw is
indistinguishable from ordinary backspace.  Actually, so is
<C-backspace>, but that was not what I meant.

Sincerely,

Luc.

Re: S-backspace

[Oliver Scholz]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Miles Bader wrote:
>    
>    On Mon, May 26, 2003 at 01:01:57AM +0200, Alex Schroeder wrote:
>    > In the new CVS, <S-backspace> runs the command kill-whole-line.
>    > I'm hitting it about twice a day by accident, confusing me.
>    > Can we reconsider this recent keybinding addition?
>
>    Yeah, I also find shift is somewhat easier to hit accidentally than
>    other modifiers, presumably because it usually has no effect, so my
>    fingers have gotten into the habit of not releasing it very quickly
>    after entering shifted letter.  So for instance if I accidentally
>    enter `M' when I meant to enter `m', I tend to hit the DEL key
>    while my brain is still processing the `release shift' concept, so
>    end up hitting S-DEL about 50% of the time...
>
> What about <M-S-backspace>.  
[...]

Uh, shift is right above ctrl on my keyboard and it is a bit larger
then ctrl. I can see myself hitting `M-C-<backspace>' accidentally
when working under X.

    Oliver
-- 
7 Prairial an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: S-backspace

[Luc Teirlinck]

Oliver Scholz wrote:

   > What about <M-S-backspace>.  
   [...]

   Uh, shift is right above ctrl on my keyboard and it is a bit larger
   then ctrl. I can see myself hitting `M-C-<backspace>' accidentally
   when working under X.

Is there any problem with <C-S-backspace>?  Will not work with, say
emacs -nw, but neither does <S-backspace> anyway.

Sincerely,

Luc.

Re: S-backspace

[Kai Großjohann]

Alex Schroeder <alex@gnu.org> writes:

> In the new CVS, <S-backspace> runs the command kill-whole-line.
> I'm hitting it about twice a day by accident, confusing me.
> Can we reconsider this recent keybinding addition?

I never suspected that this might be a problem.  I never hit
S-<backspace> by mistake.

I'll revert the keybinding and commit it tonight if I find the time,
else tomorrow.
-- 
This line is not blank.

Re: S-backspace

[Richard Stallman]

    In the new CVS, <S-backspace> runs the command kill-whole-line.
    I'm hitting it about twice a day by accident, confusing me.
    Can we reconsider this recent keybinding addition?

Since two people have already complained, clearly we must remove
this binding.

    What about <M-S-backspace>.  Given your habits, that might still give
    you problems when trying to kill an entirely capitalized word backward
    with <M-backspace>, but that would seem to be a less frequent
    situation.

Ok, let's try that one and see if there are any problems.

Re: S-backspace

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     What about <M-S-backspace>.  Given your habits, that might still give
>     you problems when trying to kill an entirely capitalized word backward
>     with <M-backspace>, but that would seem to be a less frequent
>     situation.
>
> Ok, let's try that one and see if there are any problems.

Done.
-- 
This line is not blank.

Re: S-backspace

[Rajesh Vaidheeswarran]

I believe <M-S-backspace> is already bound, in X window systems, to shutdown
the X server... so, it might be a bad idea.



In a previous message, Richard Stallman writes:

>     In the new CVS, <S-backspace> runs the command kill-whole-line.
>     I'm hitting it about twice a day by accident, confusing me.
>     Can we reconsider this recent keybinding addition?
> 
> Since two people have already complained, clearly we must remove
> this binding.
> 
>     What about <M-S-backspace>.  Given your habits, that might still give
>     you problems when trying to kill an entirely capitalized word backward
>     with <M-backspace>, but that would seem to be a less frequent
>     situation.
> 
> Ok, let's try that one and see if there are any problems.
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: S-backspace

[David Kastrup]

Rajesh Vaidheeswarran <rv@gnu.org> writes:

> I believe <M-S-backspace> is already bound, in X window systems, to shutdown
> the X server... so, it might be a bad idea.

No, that is <M-C-backspace>.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: S-backspace

[Miles Bader]

On Tue, May 27, 2003 at 10:06:53AM -0400, Rajesh Vaidheeswarran wrote:
> I believe <M-S-backspace> is already bound, in X window systems, to shutdown
> the X server... so, it might be a bad idea.

That's Ctl-Alt-backspace -- but hmmm, may be a bit too close for comfort...

-miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: S-backspace

[Kai Großjohann]

Miles Bader <miles@gnu.org> writes:

> On Tue, May 27, 2003 at 10:06:53AM -0400, Rajesh Vaidheeswarran wrote:
>> I believe <M-S-backspace> is already bound, in X window systems, to shutdown
>> the X server... so, it might be a bad idea.
>
> That's Ctl-Alt-backspace -- but hmmm, may be a bit too close for comfort...

No, C-M-<backspace> is by default bound to backward-kill-sexp.

I've killed by X server often :-/
Then I frobbed /etc/X11/XF86Config-4.

Such are the joys of unknown kbd mappings.  I still fondly remember
the day when I, used to Sun keyboards which have separate Meta and
Alt keys, came to a PC running Unixware and olvwm.  I typed a news
posting and then I hit M-q.  Emacs disappeared.  So I typed the news
posting again and then hit C-h k M-q to figure out why did Emacs
disappear.  Emacs disappeared.

I was doing this in front of a friend's Emacs.  He then said he never
uses M-q because he has F5.  (His own keybinding.)

</offtopic>

Sorry for the rant...
-- 
This line is not blank.

Re: S-backspace

[Luc Teirlinck]

Kai Grossjohann wrote:

   Such are the joys of unknown kbd mappings.  I still fondly remember
   the day when I, used to Sun keyboards which have separate Meta and
   Alt keys, came to a PC running Unixware and olvwm.  I typed a news
   posting and then I hit M-q.  Emacs disappeared.  So I typed the news
   posting again and then hit C-h k M-q to figure out why did Emacs
   disappear.  Emacs disappeared.

Yes, but conflicts with window managers are difficult to avoid.  I
believe that a good window manager should make rebinding keys
convenient.  I rebound many of the standard sawfish bindings from Meta
to Super to avoid conflicts with Emacs.  I know how to disable the X
command C-M-backspace (which I do not want to do), but somehow, I do
not know how to rebind it (to something much more difficult to hit by
accident).

Sincerely,

Luc.

Re: S-backspace

[Stefan Monnier]

> Yes, but conflicts with window managers are difficult to avoid.  I
> believe that a good window manager should make rebinding keys
> convenient.  I rebound many of the standard sawfish bindings from Meta
> to Super to avoid conflicts with Emacs.  I know how to disable the X
> command C-M-backspace (which I do not want to do), but somehow, I do
> not know how to rebind it (to something much more difficult to hit by
> accident).

I have disabled this "feature" (because I simply plug an old text-terminal
into my serial port, login, and kill the X-server, when I need the
functionality).
But before disabling it, I played tricks: the key combo is actually
control-alt-backspace and it obeys xmodmap (which I found odd), so by
having both an alt and a meta, I got to use M-C-backspace in Emacs
and C-A-backspace to kill the server.


	Stefan "longing for a remappable C-A-backspace and for an
	        similar hotkey to `kill the app that grabbed the
	        damn mouse/server/keyboard'"

Re: S-backspace

[Luc Teirlinck]

>From C-h i (emacs)Expressions:

    On some machines, `C-M-<DEL>' typed on the console is a command to
    reboot; when that is so, you cannot use it as an Emacs command.  This
    conflict is rare, though: usually the <DEL> key for Emacs is really
    <BACKSPACE>, and the reboot command is `C-M-<DELETE>', so there is no
    conflict.

One definitely should add a sentence there warning about the danger of
killing the X server under X.  C-M-<backspace> itself gives no
warning.

Sincerely,

Luc.

Re: S-backspace

[Luc Teirlinck]

Miles Bader wrote:

   That's Ctl-Alt-backspace -- but hmmm, may be a bit too close for comfort...

You are the second person complaining about that.  What about
<C-S-backspace>?  Is Shift far enough from M- and Alt- on most
keyboards?  C-S-k or, in a certain sense, C-K looks natural but might
set a bad precedent.  Of course, none of these bindings will work
under emacs -nw or the like.

Remembers me of this "fun" binding:

Caution! Danger! Do not necessarily try!

`C-M-<DEL>'
     Kill balanced expression backward (`backward-kill-sexp').

It is also bound to C-M-backspace.  Even more dangerous.  At least
C-M-<DEL> usually warns (might depend on the operating system).
C-M-backspace gives no warning.  One can disable it, but that can pose
other problems.  (On many keyboards one uses Alt for Meta.)

Sincerely,

Luc.

Re: S-backspace

[Richard Stallman]

    Caution! Danger! Do not necessarily try!

    `C-M-<DEL>'
	 Kill balanced expression backward (`backward-kill-sexp').

Perhaps we should delete that binding.  The hard thing is that it
works fine when you are not in X.

Re: S-backspace

[Stefan Monnier]

>     Caution! Danger! Do not necessarily try!
> 
>     `C-M-<DEL>'
> 	 Kill balanced expression backward (`backward-kill-sexp').
> 
> Perhaps we should delete that binding.  The hard thing is that it
> works fine when you are not in X.

Actually C-M-<DEL> is not dangerous.
C-M-backspace is the one that tends to kill the Xserver.
`function-key-map' does not map C-M-backspace to C-M-<DEL>.

As for removing the C-M-backspace binding, I'd tend to say that it's a bad
idea because I use this binding extensively (I reconfig'd my Xserver so
I could use it).


	Stefan

Re: S-backspace

[Peter Lee]

>>>> On Wed, 28 May 2003 20:25:54 -0400, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> said:
    Stefan> As for removing the C-M-backspace binding, I'd tend to say
    Stefan> that it's a bad idea because I use this binding
    Stefan> extensively (I reconfig'd my Xserver so I could use it).

I second this... I went through the same thing. Being new to x, it
took me a while to figure out why every once in a while it would just
die.  Heh.

Re: S-backspace

[Oliver Scholz]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

>>     Caution! Danger! Do not necessarily try!
>> 
>>     `C-M-<DEL>'
>> 	 Kill balanced expression backward (`backward-kill-sexp').
>> 
>> Perhaps we should delete that binding.  The hard thing is that it
>> works fine when you are not in X.
>
> Actually C-M-<DEL> is not dangerous.

It tells init to reboot the operating system when you are working on a
tty.

> C-M-backspace is the one that tends to kill the Xserver.
> `function-key-map' does not map C-M-backspace to C-M-<DEL>.
>
> As for removing the C-M-backspace binding, I'd tend to say that it's a bad
> idea because I use this binding extensively (I reconfig'd my Xserver so
> I could use it).
[...]

It doesn't matter anyways, because it is part of the structure of the
commands that move around sexprs. The first time I killed my X-Server
I simply wanted to 'kill the s-expression before point'. I didn't
read in the documentation that this command exists and that it is
bound to `C-M-<backspace>'; it's just the logical binding when you
are familiar with `M-C-a', `M-C-f' etc.

But I'd vote against binding `kill-whole-line' to
`S-M-<backspace>'. The penalty for clumsy fingers is way to high. I'd
have to be carefule and assure that I set my fingers right in order
to use this command -- which means that it would me more inconvenient
and complicated than `C-a C-k C-k', so I won't use it.

[C-S-<backspace>, or still better: `C-S-k' is fine, IMO.]

    Oliver
-- 
10 Prairial an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: S-backspace

[Luc Teirlinck]

Oliver Scholz wrote:

   But I'd vote against binding `kill-whole-line' to
   `S-M-<backspace>'. The penalty for clumsy fingers is way to high. I'd
   have to be carefule and assure that I set my fingers right in order
   to use this command -- which means that it would me more inconvenient
   and complicated than `C-a C-k C-k', so I won't use it.

   [C-S-<backspace>, or still better: `C-S-k' is fine, IMO.]

C-S-<backspace> is probably safer than S-M-<backspace>.

C-S-k is more intuitive.  However, are there people who actually use
the Caps Lock key?  Because C-S-k might give them trouble.

Sincerely,

Luc.

Re: S-backspace

[Luc Teirlinck]

>From a message I sent several days ago:

   Oliver Scholz wrote:

      But I'd vote against binding `kill-whole-line' to
      `S-M-<backspace>'. The penalty for clumsy fingers is way to high. I'd
      have to be carefule and assure that I set my fingers right in order
      to use this command -- which means that it would me more inconvenient
      and complicated than `C-a C-k C-k', so I won't use it.

      [C-S-<backspace>, or still better: `C-S-k' is fine, IMO.]

   C-S-<backspace> is probably safer than S-M-<backspace>.

   C-S-k is more intuitive.  However, are there people who actually use
   the Caps Lock key?  Because C-S-k might give them trouble.

Are there any objections against changing the binding of
kill-whole-line from M-S-<backspace> to C-S-<backspace>?
(To avoid people accidentally killing their X server by hitting the
wrong key.)  I could commit that change if there are no objections.

Sincerely,

Luc.

Re: S-backspace

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>    C-S-<backspace> is probably safer than S-M-<backspace>.
> 
>    C-S-k is more intuitive.  However, are there people who actually use
>    the Caps Lock key?  Because C-S-k might give them trouble.
> 
> Are there any objections against changing the binding of
> kill-whole-line from M-S-<backspace> to C-S-<backspace>?
> (To avoid people accidentally killing their X server by hitting the
> wrong key.)  I could commit that change if there are no objections.

I think C-S-k is better (easier to type, and more intuitive).

-Miles
-- 
Run away!  Run away!

Re: { SPAM 2 }::Re: S-backspace

[Luc Teirlinck]

Miles Bader wrote:

   I think C-S-k is better (easier to type, and more intuitive).

We could bind it to C-S-k, if there are no objections.  I personally
do not use the Caps Lock key and nobody I know does.  However,
keyboard manufacturers seem to have the irresistible urge to put a
Caps Lock key on their products.  Is the intent merely to make sure
that their customers understand the importance of xmodmap or are there
people actually using that key?  In the latter case, they would
probably not like the C-S-k binding.

Sincerely,

Luc.

Re: S-backspace

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> >     Caution! Danger! Do not necessarily try!
> > 
> >     `C-M-<DEL>'
> > 	 Kill balanced expression backward (`backward-kill-sexp').
> > 
> > Perhaps we should delete that binding.  The hard thing is that it
> > works fine when you are not in X.
> 
> Actually C-M-<DEL> is not dangerous.
> C-M-backspace is the one that tends to kill the Xserver.

And C-M-DEL is the one that reboots the machine if you are on a text
console.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: S-backspace

[Luc Teirlinck]

Richard Stallman wrote:

       Caution! Danger! Do not necessarily try!

       `C-M-<DEL>'
	    Kill balanced expression backward (`backward-kill-sexp').

   Perhaps we should delete that binding.  The hard thing is that it
   works fine when you are not in X.

The binding itself is clearly not dangerous, once Emacs even gets to
see the binding the danger is over.  The danger consists in
encouraging people to use it without properly warning them.  I
suggested adding such a warning to the relevant section of the Emacs
manual.

There are four closely related bindings involved:  C-M-<DEL>,
C-Alt-<DEL>, C-M-<backspace> and C-Alt-<backspace>.

Strictly speaking, as Stefan remarked, the one that kills the X server
is C-Alt-<backspace>, but many keyboards do not have separate Alt and
Meta keys, making the last two key-combinations very dangerous.  Adding
a shift key to these last two ones is no help: the X server gets
killed anyway.

The two first ones are used for logout on many operating systems.  All
those I know of warn (actually even present several options), leading
to inconvenience and confusion rather than outright danger.  Moreover,
here shifting does seem to work.  (This may not work for all operating
systems.  It is sufficient if it works for operating systems using X.
Otherwise, one can use C-M-backspace.)  On my system, C-M-<DEL> is
controlled by sawfish, which binds it to "gnome logout".  In my .emacs
I bind C-M-S-<DEL> to `backward-kill-sexp', sawfish ignores it because
of the shift key, and everything seems to work fine.  It does not work
under emacs -nw, but plenty of bindings do not seem to work under
emacs -nw.

So what about the following solution:

1.  Explain the dangers in the relevant section of the Emacs manual.

2.  Add C-M-S-<DEL> as a binding for backward-kill-sexp.

Sincerely,

Luc.

Re: S-backspace

[Luc Teirlinck]

>From my previous message:

   So what about the following solution:

   1.  Explain the dangers in the relevant section of the Emacs manual.

   2.  Add C-M-S-<DEL> as a binding for backward-kill-sexp.

Of course, if one would do 2. , then one should tell people explicitly
that C-M-S-<backspace> is not a valid alternative under X, because that
kills the X server just as well as C-M-<backspace>.

Sincerely,

Luc.

Re: S-backspace

[Richard Stallman]

    The binding itself is clearly not dangerous, once Emacs even gets to
    see the binding the danger is over.  The danger consists in
    encouraging people to use it without properly warning them.

That is true.  But there are Emacs help commands that will display
the binding and won't display any additional information.
For instance, C-h w backward-kill-sexp says

    backward-kill-sexp is on <C-M-backspace>, <C-M-delete>, ESC <C-backspace>, ESC <C-delete>

C-M-backspace seems to be a danger under XFree86, and you've said that
C-M-delete might also be one with some window managers (though not
with mine).  Meanwhile, C-M-delete causes a reboot on the console,
but C-M-backspace doesn't.

    It doesn't matter anyways, because it is part of the structure of the
    commands that move around sexprs. The first time I killed my X-Server
    I simply wanted to 'kill the s-expression before point'. I didn't
    read in the documentation that this command exists and that it is
    bound to `C-M-<backspace>'; it's just the logical binding when you
    are familiar with `M-C-a', `M-C-f' etc.

I guess nothing we might do can close that pitfall.  But in addition
to people who deduce this command ought to exist, there must be others
who read about it.

Since this command is not often used, I think the danger exceeds the
utility.  I am coming to think that the best thing to do is to delete
both bindings, and let real Emacs wizards who want a key binding for
this command make one themselves.


All in all, the situation created by XFree86 and Linux is a confusing
one.  Given that XFree86 turns off the Linux handling of C-M-delete as
a command to reboot, shouldn't it use C-M-delete for killing the X
server, rather than C-M-backspace?  That way, one key would be used by
the system for two similar purposes depending on the situation, and
the other key would always be available for other programs.

Re: S-backspace

[Kevin Rodgers]

Richard Stallman wrote:

> All in all, the situation created by XFree86 and Linux is a confusing
> one.  Given that XFree86 turns off the Linux handling of C-M-delete as
> a command to reboot, shouldn't it use C-M-delete for killing the X
> server, rather than C-M-backspace?  That way, one key would be used by
> the system for two similar purposes depending on the situation, and
> the other key would always be available for other programs.

Wouldn't it be nice if the kernel, OS, window system, and window manager could

be queried to find out which keys each of them traps to kill/restart itself?

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: S-backspace

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> 
> All in all, the situation created by XFree86 and Linux is a confusing
> one.  Given that XFree86 turns off the Linux handling of C-M-delete as
> a command to reboot, shouldn't it use C-M-delete for killing the X
> server, rather than C-M-backspace? 

Well, that would cause other rather severe problems in some setups.

Consider the following setup which I guess is quite common for those
of us who want free software on our systems, but need to use non-free
software (for some tasks) to earn a living:

On my GNU/Linux box at work, I run a vmware virtual machine under X,
and inside that virtual machine I run Windows XP (to access the
company Intranet).  Now, to log into Windows XP, I need to press
C-A-delete (ie. C-M-delete); so it is _very_ fortunate that neither
Linux nor XFree86 uses that key sequence to restart the machine or the
X server.

Having said that, I think the choice of C-M-backspace to restart
the X-server is a very bad choice ... something like C-M-S-SysReq
or whatever obscure sequence would be better.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: S-backspace

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

|> Having said that, I think the choice of C-M-backspace to restart
|> the X-server is a very bad choice ... something like C-M-S-SysReq
|> or whatever obscure sequence would be better.

Not all keyboards have a SysReq key.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: S-backspace

[Luc Teirlinck]

Richard Stallman wrote:

   That is true.  But there are Emacs help commands that will display
   the binding and won't display any additional information.

Yes, that is a danger.

   and you've said that C-M-delete might also be one with some window
   managers (though not with mine).

Well, on my system C-M-delete is bound by sawfish to "gnome logout",
but, unlike C-M-backspace, you get asked: "Really logout?" and you can
answer no.  More inconvenience and confusion than real danger.

   Since this command is not often used, I think the danger exceeds the
   utility.  I am coming to think that the best thing to do is to delete
   both bindings, and let real Emacs wizards who want a key binding for
   this command make one themselves.

Actually, the command might be reasonably often used, but mainly while
editing Lisp programs, that is, by people who should know how to bind
it to any key of their choice.  Maybe it might be good not to bind the
command by default, but to mention the command in the Emacs manual,
together with the fact that C-M-delete and C-M-backspace would be
logical bindings, but also what the dangers are and under which
conditions these bindings are safe.

Sincerely,

Luc.

Re: S-backspace

[Miles Bader]

On Fri, May 30, 2003 at 07:39:15PM -0500, Luc Teirlinck wrote:
> Actually, the command might be reasonably often used, but mainly while
> editing Lisp programs, that is, by people who should know how to bind
> it to any key of their choice.

I edit a lot of lisp programs, and I find I just use `C-M-b C-M-k' -- it's
actually easier to type, since you can just hold down the C-M- keys, and
doesn't involve any `stretch' keys like DEL.

You can actually move around easily while still holding the C-M- keys (e.g.,
hold down C-M- and then hit `u u b') before hitting `k', and I don't find
that deleting the _previous_ sexp is common enough to really warrant a
dedicated bit of space in my brain...

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: S-backspace

[Luc Teirlinck]

Miles Bader wrote:

   I edit a lot of lisp programs, and I find I just use `C-M-b C-M-k' -- it's
   actually easier to type, since you can just hold down the C-M- keys, and
   doesn't involve any `stretch' keys like DEL.

That is indeed one way to get the task done.

Sincerely,

Luc.

Re: S-backspace

[Miles Bader]

On Fri, May 30, 2003 at 07:58:11PM -0500, Luc Teirlinck wrote:
>    I edit a lot of lisp programs, and I find I just use `C-M-b C-M-k' -- it's
>    actually easier to type, since you can just hold down the C-M- keys, and
>    doesn't involve any `stretch' keys like DEL.
> 
> That is indeed one way to get the task done.

Yeah, but my point was that in practice it's actually _better_, so there's
really not much need for a default `C-M-DEL' binding.

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: S-backspace

[Jan D.]

tisdagen den 27 maj 2003 kl 16.06 skrev Rajesh Vaidheeswarran:

> I believe <M-S-backspace> is already bound, in X window systems, to 
> shutdown
> the X server... so, it might be a bad idea.

Actually it is C-M-backspace and Xfree86 only.

	Jan D.

Re: S-backspace

[Richard Stallman]

    I believe <M-S-backspace> is already bound, in X window systems, to shutdown
    the X server... so, it might be a bad idea.

That command is C-M-backspace, not S-M-backspace.
However, someone mentioned the possibility of typing
C-M-backspace by mistake when trying to type S-M-backspace.

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

> > I have found a variable called rmail-enable-mime, and some void
> > variables of type rmail-*-mime-* which don't fit into my
> > implementation and I don't understand why they are here anyway.
> 
> IIRC, this is for add-on packages that add MIME support to RMAIL.

Do you know of such a package? I was not able to find any.
If there exist some, I don't want to break it. Otherwise I don't
believe those variables are useful.

> > 2) If I save an email to the file, I want it to be the same message
> >    as RMail read from my mailbox. I want to be able to read it from
> >    another mail client, for example.
> 
> Someone wrote code to do that, but it's currently on a separate
> branch of the Emacs CVS.  I suggest to leave this issue alone, not to
> mix it with the other changes you did.

Actually, I ment rmail-output function from rmailout.el file, but
after consideration I agree that I used that functionality so often
only because there was no better way to get attached files from the
email. Normally I don't need to export emails to files.

> > 3) I agree that some action (transfer-/charset decoding, PGP signature
> >    verification, etc.) is OK to do once in function called from
> >    rmail-convert-to-babyl-format, but some other (picture previews,
> >    big attachement hiding, etc.) should be done by every (?)
> >    rmail-show-message call.
> 
> I suggest to discuss this (on emacs-devel).  There are trade-offs here
> that IMHO are not so trivial to resolve.

OK, this is how I see it.

When we convert the email to babyl format, we can do some MIME-related
processing on it, for example: all text/* bodyparts may be
transfer-encoding (quoted-printable and base64) decoded, PGP/GPG
signatures verified, PGP/GPG decryption done, header fields of type
=?...?B?...?= decoded (RFC 2047) and unfolded (RFC 2822), etc.
This needs to be done once. No information is lost in this step. No
structure information is lost either.

When we show the message, I'm not interested in following things:
* MIME-related boundaries;
* Header fields of most entities;
* Entities of some types (multipart/alternative(text/html),
pgp-signature, etc);
* Entities of types image, audio, video, application. Instead, I would
like to see a button [Save as...] which will save an entity to file;
* Entities of types image/jpeg, image/png, etc. may be displayed right
here in the buffer.

Granted, we can delete boundaries and header field we don't want to
see, but what to do with big bodyparts like attached images? Where to
store them so that the user does not normally see them, but can
access them anytime in the future?

Also, please note that if we delete any MIME-related information, we
will not be able to parse the message again later. Well, we will need
some other parser. This way we invent another format. I don't like
this, that's why I don't agree that we should delete something we
don't want to see on the screen.
As I proposed before, I would like to hide the information using the
"invisible" property. I'm open to suggestions.


Another problem is that we currently brake the email by inserting
"simplified" header between original header and the message body (in
rmail-reformat-message function). After this is done, MIME-parsing
function does not work anymore.

I would very like to hear your ideas.
Thanks to anybody in advance.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Kenichi Handa]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

In article <200310121947.h9CJlhKH006102@oak.pohoyda.family>, Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:
>>  > I have found a variable called rmail-enable-mime, and some void
>>  > variables of type rmail-*-mime-* which don't fit into my
>>  > implementation and I don't understand why they are here anyway.
>>  
>>  IIRC, this is for add-on packages that add MIME support to RMAIL.

> Do you know of such a package? I was not able to find any.

Morioka-san developped such a package.  The several
rmail-*-mime-*-function are introduced for that package.
I'll attach it at the tail.  But, unfortunately, before
releasing that package officially, he moved to another
organization and got very busy.  It decodes a message into
another buffer (rmail-view-buffer) without modifying RMAIL
buffer itself.  As far as I know, one problem with this
package is that it's very slow in rmail-search[-backward].

> If there exist some, I don't want to break it. Otherwise I don't
> believe those variables are useful.

It seems that we can't expect Morioka-san to work on
rmail-mime package, at least, for a while.  So, if keeping
those variables is very difficult, I think you can delete
them.

---
Ken'ichi HANDA
handa@m17n.org


[-- Attachment #2: rmail-mime.tar.gz --]
[-- Type: application/octet-stream, Size: 193573 bytes --]

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: RMAIL, MIME-related bug

[Robert J. Chassell]

    >>  IIRC, this is for add-on packages that add MIME support to RMAIL.
    > Do you know of such a package? I was not able to find any.

Take a look at rmime.el.  I have been using it with no trouble.

Here is how rmime.el describes itself:

    ;;; rmime.el --- read MIME messages

    ;; Author: Ray Moody <moody@cray.com>
    ;; Version: $Id: rmime.el,v 1.2 1996/05/30 02:24:58 moody Exp $
    ;; Charset support version 0.3 by J. Chroboczek <jec@dcs.ed.ac.uk>
    ;; Keywords: MIME, mail

    ;;; Commentary:

    ;; RMIME provides MIME support for several Emacs message reading
    ;; packages.  RMIME has been designed with RMAIL in mind, but it has
    ;; also been tested with mh-e and VM.  It should work with most other
    ;; major modes as well.

Before loading rmime.el, you need to load charset.el, which is in a
library from 1996 written by Juliusz Chroboczek <jec@dcs.ed.ac.uk>.

The rmime.el file says to put this into your .emacs file:

    ;;	(add-hook 'rmail-show-message-hook 'rmime-format)
    ;;	(add-hook 'rmail-edit-mode-hook    'rmime-cancel)
    ;;	(autoload 'rmime-format "rmime" "" nil)

but I do this:

    (load "charset")
    (load "rmime")
    (set-face-foreground 'rmime-markup-face "cyan")
    (define-key rmail-mode-map [f7] 'rmime-mode) ; fn key F7

(For creating MIME messages, I use Marc Andreessen's mime-compose.el,
which he wrote in 1992 before he started Netscape.)

Also, you need to have installed mimencode and then, since the names
have changed, to symbollically link mmencode to mimencode:

    ln -s mimencode mmencode

This works in today's CVS snapshot, Tue, 2003 Oct 14  12:16 UTC
GNU Emacs 21.3.50.118 (i686-pc-linux-gnu, GTK+ Version 2.2.1)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

`whitespace-describe' function missing

[Robert J. Chassell]

    Today's GNU Emacs CVS snapshot, Fri, 2003 Apr 11  12:37 UTC

In `lisp/whitespace.el', the `whitespace-cleanup' function says

    Use \\[describe-function] whitespace-describe to read a summary of the
    whitespace problems."

but the `whitespace-describe' function does not exist!

The `whitespace problems' are described in the `whitespace-buffer'
function and in the `lisp/whitespace.el' commentary.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: `whitespace-describe' function missing

[Rajesh Vaidheeswarran]

Hi,

I'm not sure which version of whitespace.el you are using...

but, the function does exist in 3.1 (installed with emacs on fencepost)
and 3.2, which I had checked out last from subversions... 

rv

;;;###autoload
(defun whitespace-describe ()
  "A summary of whitespaces and what this library can do about them.

The whitespace library is intended to find and help fix five different types
of whitespace problems that commonly exist in source code.

1. Leading space (empty lines at the top of a file).
2. Trailing space (empty lines at the end of a file).
3. Indentation space (8 or more spaces at beginning of line, that should be
		      replaced with TABS).
4. Spaces followed by a TAB.  (Almost always, we never want that).
5. Spaces or TABS at the end of a line.

Whitespace errors are reported in a buffer, and on the modeline.

Modeline will show a W:<x>!<y> to denote a particular type of whitespace,
where `x' and `y' can be one (or more) of:

e - End-of-Line whitespace.
i - Indentation whitespace.
l - Leading whitespace.
s - Space followed by Tab.
t - Trailing whitespace.

If any of the whitespace checks is turned off, the modeline will display a
!<y>.

    (since (3) is the most controversial one, here is the rationale: Most
    terminal drivers and printer drivers have TAB configured or even
    hardcoded to be 8 spaces.  (Some of them allow configuration, but almost
    always they default to 8.)

    Changing `tab-width' to other than 8 and editing will cause your code to
    look different from within Emacs, and say, if you cat it or more it, or
    even print it.

    Almost all the popular programming modes let you define an offset (like
    c-basic-offset or perl-indent-level) to configure the offset, so you
    should never have to set your `tab-width' to be other than 8 in all these
    modes.  In fact, with an indent level of say, 4, 2 TABS will cause Emacs
    to replace your 8 spaces with one \t (try it).  If vi users in your
    office complain, tell them to use vim, which distinguishes between
    tabstop and shiftwidth (vi equivalent of our offsets), and also ask them
    to set smarttab.)

All the above have caused (and will cause) unwanted codeline integration and
merge problems.

whitespace.el will complain if it detects whitespaces on opening a file, and
warn you on closing a file also (in case you had inserted any
whitespaces during the process of your editing)."
  (interactive)
  (message "Use C-h f whitespace-describe to read about whitespace.el v%s."
	   whitespace-version))





In a previous message, "Robert J. Chassell" writes:

>     Today's GNU Emacs CVS snapshot, Fri, 2003 Apr 11  12:37 UTC
> 
> In `lisp/whitespace.el', the `whitespace-cleanup' function says
> 
>     Use \\[describe-function] whitespace-describe to read a summary of the
>     whitespace problems."
> 
> but the `whitespace-describe' function does not exist!
> 
> The `whitespace problems' are described in the `whitespace-buffer'
> function and in the `lisp/whitespace.el' commentary.
> 
> -- 
>     Robert J. Chassell                         Rattlesnake Enterprises
>     http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
>     http://www.teak.cc                             bob@rattlesnake.com
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 

Re: `whitespace-describe' function missing

[Robert J. Chassell]

   I'm not sure which version of whitespace.el you are using...

    ;; $Id: whitespace.el,v 1.22 2002/12/03 00:10:40 schwab Exp $

Hah!  The log says that the function was removed on 2002/09/11.  
I should have read the log earlier.  My mistake.

Here is the log entry:

 revision 1.20
 date: 2002/09/11 21:30:25;  author: monnier;  state: Exp;  lines: +62 -87
 (whitespace-global-mode): Use define-minor-mode.  Use the new file hook names.
 (whitespace-describe): Remove.  Move the text to `Commentary:'.
 (whitespace-unload-hook): Use the new file hook names.

That is why the function is not in the in the current CVS instance of
the whitespace.el file, which is

    ;; $Id: whitespace.el,v 1.22 2002/12/03 00:10:40 schwab Exp $


Incidentally, while you could re-include your function definition of
`whitespace-describe' in the CVS, it is surprising to see
documentation like that.  I would expect to see the full documentation
in the documentation strings of:

    whitespace-buffer
    whitespace-region
    whitespace-cleanup

as well as in the commentary and in the Texinfo documentation.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: `whitespace-describe' function missing

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>  (whitespace-describe): Remove.  Move the text to `Commentary:'.

IMO, it doesn't really make sense to have a function which produces
the help for a given package, as there sufficient other ways to
provide that information  (BTW printing.el is another package which
does this).

In any case, when the source file has valuable inforation in the
commentary section, there should at least be a Commentary link on the
customization section for whitespace-global-mode; I believe one can be
added to the define-minor-mode as
 :link '(emacs-commentary-link :tag "Commentary" "whitespace.el")
but I haven't tried it.

 
> Incidentally, while you could re-include your function definition of
> `whitespace-describe' in the CVS, it is surprising to see
> documentation like that.  I would expect to see the full documentation
> in the documentation strings of:
> 
>     whitespace-buffer
>     whitespace-region
>     whitespace-cleanup
> 
> as well as in the commentary and in the Texinfo documentation.

Maybe we could find a way to make commentary links from doc strings
to the lisp file?  E.g. with an extra button like "See also" ...


| whitespace-global-mode's value is nil
| 
| Non-nil if Whitespace-Global mode is enabled.
| See the command `whitespace-global-mode' for a description of this minor-mode.
| Setting this variable directly does not take effect;
| use either M-x customize or the function `whitespace-global-mode'.
+
+ See also _Commentary_
| 
| You can customize this variable.
| 
| Defined in `whitespace'.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: `whitespace-describe' function missing

[Rajesh Vaidheeswarran]

Sorry for a long delay... 

I just got the access to subversions fixed.. and added the :link to
the commentary section as you suggested.. However, I'm not sure there
was any pereptible change in the customization section.

Please feel free to diff the change and let me know if there was anything
that I missed.

Regarding the `whitespace-describe' ... 

It seemed appropriate to me that there be something central that
described the library and its purpose. The doc strings in each of the
defuns, I believed, were to describe what the defun did, and not to
describe any higher level functionality of the library itself.

In the case of whitespace.el, I'd have had to duplicate a lot of the
docstrings all over the place, since all the defuns basically are
checking / fixing the same set of whitespaces.

If you feel there is a better way, whereby we wouldn't have to duplicate
docstrings, and also present documentation on the library itself, please
let me know..

I thought the Commentary link was neat, but it didn't seem to work for me.
If it did, I'd have nixed whitespace-describe and moved the lib description
to the Commentary section.

Thanks
rv

In a previous message, Kim F. Storm writes:

> "Robert J. Chassell" <bob@rattlesnake.com> writes:
> 
> >  (whitespace-describe): Remove.  Move the text to `Commentary:'.
> 
> IMO, it doesn't really make sense to have a function which produces
> the help for a given package, as there sufficient other ways to
> provide that information  (BTW printing.el is another package which
> does this).
> 
> In any case, when the source file has valuable inforation in the
> commentary section, there should at least be a Commentary link on the
> customization section for whitespace-global-mode; I believe one can be
> added to the define-minor-mode as
>  :link '(emacs-commentary-link :tag "Commentary" "whitespace.el")
> but I haven't tried it.
> 
>  
> > Incidentally, while you could re-include your function definition of
> > `whitespace-describe' in the CVS, it is surprising to see
> > documentation like that.  I would expect to see the full documentation
> > in the documentation strings of:
> > 
> >     whitespace-buffer
> >     whitespace-region
> >     whitespace-cleanup
> > 
> > as well as in the commentary and in the Texinfo documentation.
> 
> Maybe we could find a way to make commentary links from doc strings
> to the lisp file?  E.g. with an extra button like "See also" ...
> 
> 
> | whitespace-global-mode's value is nil
> | 
> | Non-nil if Whitespace-Global mode is enabled.
> | See the command `whitespace-global-mode' for a description of this minor-mo
> de.
> | Setting this variable directly does not take effect;
> | use either M-x customize or the function `whitespace-global-mode'.
> +
> + See also _Commentary_
> | 
> | You can customize this variable.
> | 
> | Defined in `whitespace'.
> 
> 
> -- 
> Kim F. Storm <storm@cua.dk> http://www.cua.dk
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 

Re: `whitespace-describe' function missing

[Stefan Monnier]

> It seemed appropriate to me that there be something central that
> described the library and its purpose. The doc strings in each of the

That's what the Commentary section is for.

> I thought the Commentary link was neat, but it didn't seem to work for me.

So we should fix it.


	Stefan

Re: RMAIL, MIME-related bug

[Peter S Galbraith]

Robert J. Chassell <bob@rattlesnake.com> wrote:

>     >>  IIRC, this is for add-on packages that add MIME support to RMAIL.
>     > Do you know of such a package? I was not able to find any.
> 
> Take a look at rmime.el.  I have been using it with no trouble.
> 
> Here is how rmime.el describes itself:
> 
>     ;;; rmime.el --- read MIME messages
> 
>     ;; Author: Ray Moody <moody@cray.com>
>     ;; Version: $Id: rmime.el,v 1.2 1996/05/30 02:24:58 moody Exp $
>     ;; Charset support version 0.3 by J. Chroboczek <jec@dcs.ed.ac.uk>
>     ;; Keywords: MIME, mail
> 
>     ;;; Commentary:
> 
>     ;; RMIME provides MIME support for several Emacs message reading
>     ;; packages.  RMIME has been designed with RMAIL in mind, but it has
>     ;; also been tested with mh-e and VM.  It should work with most other
>     ;; major modes as well.

Note: It probably doesn't work with modern MH-E as it handles MIME
natively.

Another avenue for rmail developers is to borrow some MIME support code
from MH-E which was borrowed from gnus.  (It might actually be easier to
isolate in the MH-E code.)

bootstrap from scratch

[Robert J. Chassell]

Today, I removed *all* my Emacs' CVS sources using `rm -rf emacs' and
checked out fresh sources.  The `59 Temple Place' zipcode is now
correct.  My earlier report was based on a damaged set of sources.
Please ignore it.

Since I had new sources, I could configure and bootstrap build with a
completely fresh CVS Emacs.

The good news is that the bootstrap mostly worked.
The bad news is that the bootstrap failed once.

One bug appeared when I used this command:

     (progn
       (cd "/usr/local/src/emacs/")
       (compile
        "./configure --with-type1 \
         --with-x-toolkit=gtk \
         --prefix=/usr/local --with-sound=yes \
         && time make bootstrap"))

During the build, compilation halted and I was asked to

             "Enter longitude (decimal fraction; + east, - west): "

which is a prompt from     emacs/lisp/calendar/solar.el

However, I could not enter that information into the *compilation*
buffer, since it is read-only.

So I prepended my location to `emacs/lisp/calendar/solar.el' using
`setq calendar-latitude' and `setq calendar-longitude' expression.
The next bootstrap build, which took two hours, then reported no
errors.

Perhaps `calendar-latitude' and `calendar-longitude' should be set to
0.0 rather than nil by defcustom.  (I have done that, but tested it
only with a `make recompile', since I do not want to do a bootstrap
again.)

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: bootstrap from scratch

[Ed Reingold]

> Perhaps `calendar-latitude' and `calendar-longitude' should be set to
> 0.0 rather than nil by defcustom.  (I have done that, but tested it
> only with a `make recompile', since I do not want to do a bootstrap
> again.)

Very bad idea.  Then a user will never know that the times of events (solar/
lunar times) are garbage.

Re: bootstrap from scratch

[Robert J. Chassell]

    During a bootstrap build, compilation halted at a prompt from
    emacs/lisp/calendar/solar.el

    However, I could not enter that information into the *compilation*
    buffer, since it is read-only.

As a fix, I suggested

    Perhaps `calendar-latitude' and `calendar-longitude' should be set
    to 0.0 rather than nil by defcustom.

Ed Reingold <reingold@emr.cs.iit.edu> wrote

   Very bad idea.  Then a user will never know that the times of
   events (solar/ lunar times) are garbage.

which is a good argument.  

However, the *compilation* buffer is read-only.  Presumably, the user
could be prompted to type `C-x C-q' (toggle-read-only) in Emacs and
then enter the information.

However, the query stops compilation in the middle of what may be a
long build that the person is not watching.  So that solution is no
good.

Perhaps it would be better to set `calendar-latitude' to 51.5 and
`calendar-longitude' to 0.0 by default but then tell people who want
to learn about solar and lunar times that that default location is for
Greenwich, England.  That info should go away if `calendar-latitude'
and `calendar-longitude' are set to any other value.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: bootstrap from scratch

[Ed Reingold]

> Perhaps it would be better to set `calendar-latitude' to 51.5 and
> `calendar-longitude' to 0.0 by default but then tell people who want
> to learn about solar and lunar times that that default location is for
> Greenwich, England.  That info should go away if `calendar-latitude'
> and `calendar-longitude' are set to any other value.

Still a bad idea, for the same reason: Emacs will display times of solar and 
lunar phenomena that are wrong, but subtly so.  The only default value must be 
nil so that any calculations are trapped.

This is a conundrum: Any value that lets the compilation proceed will 
(necessarily) produce wrong results.  Any value that stops the calculation if 
the latitude/longitude/zone are not set will stop compilation.  Silly.

Re: bootstrap from scratch

[Alan Shutko]

Ed Reingold <reingold@emr.cs.iit.edu> writes:

> This is a conundrum: Any value that lets the compilation proceed will 
> (necessarily) produce wrong results.  Any value that stops the calculation if 
> the latitude/longitude/zone are not set will stop compilation.  Silly.

Why does it need to use the latitude and longitude at compilation
time?  If we fix that, it doesn't matter what the default is.

-- 
Alan Shutko <ats@acm.org> - I am the rocks.
"City Morgue--you kill 'em, we chill 'em; you stab 'em, we slab 'em!"

Re: bootstrap from scratch

[Ed Reingold]

> Ed Reingold <reingold@emr.cs.iit.edu> writes:
> 
> > This is a conundrum: Any value that lets the compilation proceed will 
> > (necessarily) produce wrong results.  Any value that stops the calculation if 
> > the latitude/longitude/zone are not set will stop compilation.  Silly.
> 
> Why does it need to use the latitude and longitude at compilation
> time?  If we fix that, it doesn't matter what the default is.


An excellent question!!

Re: bootstrap from scratch

[Alan Shutko]

Alan Shutko <ats@acm.org> writes:

> Why does it need to use the latitude and longitude at compilation
> time?  If we fix that, it doesn't matter what the default is.

So, here's the problem.

On load, appt.el calls (appt-activate 1).  That activates the
appointment stuff, which loads the diary file.  If the user has a
diary file with diary-sunrise-sunset in it, diary-sunrise-sunset is
called, which tries to use the latitude and longitude.

icalendar.el has (require 'appt).  So, when icalendar.el is compiled,
appt is loaded and activated.  Enter the problem.

Here's what I have as a possible fix.  It will fix bootstrap, but it
won't fix the case if someone is interactively compiling a file which
requires appt, and doesn't have lat & long set.

2005-05-05  Alan Shutko  <ats@acm.org>

	* calendar/appt.el: Only activate appt if in an interactive
	session.  This stops appt from prompting during Emacs bootstrap.

--- appt.el	31 Mar 2005 08:33:46 -0600	1.57
+++ appt.el	05 May 2005 14:20:30 -0500	
@@ -1,6 +1,7 @@
 ;;; appt.el --- appointment notification functions
 
-;; Copyright (C) 1989, 1990, 1994, 1998, 2004  Free Software Foundation, Inc.
+;; Copyright (C) 1989, 1990, 1994, 1998, 2004, 2005
+;;	Free Software Foundation, Inc.
 
 ;; Author: Neil Mager <neilm@juliet.ll.mit.edu>
 ;; Maintainer: Glenn Morris <gmorris@ast.cam.ac.uk>
@@ -689,8 +690,8 @@
 
 
 ;; This is needed for backwards compatibility. Feh.
-(appt-activate 1)
-
+(if (not noninteractive)
+    (appt-activate 1))
 
 (provide 'appt)
 



-- 
Alan Shutko <ats@acm.org> - I am the rocks.
Next to ingratitude, the most painful thing to bear is gratitude.

Re: bootstrap from scratch

[Ed Reingold]

> Here's what I have as a possible fix.  It will fix bootstrap, but it
> won't fix the case if someone is interactively compiling a file which
> requires appt, and doesn't have lat & long set.

Presumably anyone requiring appt AND using the solar/lunar stuff will have 
that set already!

Re: bootstrap from scratch

[Glenn Morris]

Alan Shutko wrote:

> So, here's the problem.

Thanks for the diagnosis Alan!

Clearly, ignore my previous mailing on this subject, and a thousand
apologies for casting (however vague) aspersions in the direction of
org.el! :)

org.el fix

[Alan Shutko]

Glenn Morris <gmorris+emacs@ast.cam.ac.uk> writes:

> Clearly, ignore my previous mailing on this subject, and a thousand
> apologies for casting (however vague) aspersions in the direction of
> org.el! :)

Speaking of which,

2005-05-05  Alan Shutko  <ats@acm.org>

	* textmodes/org.el (org-store-link): Fix parens.

--- org.el	05 May 2005 13:43:08 -0500	1.16
+++ org.el	05 May 2005 13:59:07 -0500	
@@ -4868,7 +4868,7 @@
         (setq link (concat (if (org-xor arg org-usenet-links-prefer-google)
                                "http://groups.google.com/groups?group="
                              "gnus:")
-                           group)))))
+                           group))))
 
      ((memq major-mode '(gnus-summary-mode gnus-article-mode))
       (and (eq major-mode 'gnus-article-mode) (gnus-article-show-summary))

-- 
Alan Shutko <ats@acm.org> - I am the rocks.
You tell 'em Gambler, You've got winning ways.

Re: bootstrap from scratch

[Stefan Monnier]

> On load, appt.el calls (appt-activate 1).

That's a bug.


        Stefan

Re: bootstrap from scratch

[Glenn Morris]

Stefan Monnier wrote:

>> On load, appt.el calls (appt-activate 1).
>
> That's a bug.

As the comment says, it's necessary for backwards compatibility, and I
wasn't particularly happy about having to do it.

Loading appt.el used to activate the appointment package (in a
convoluted way, I think; can't remember the details now). When I
changed it so it did not, I had an email from someone saying he had
missed a bunch of appointments.

So I had to make loading the package activate it, for "historical
reasons".

Re: bootstrap from scratch

[Kim F. Storm]

Glenn Morris <gmorris+emacs@ast.cam.ac.uk> writes:

> As the comment says, it's necessary for backwards compatibility, and I
> wasn't particularly happy about having to do it.

I think you should add the following paragraph to the comment,
to explain why "backwards compatibility" is needed:
>
> Loading appt.el used to activate the appointment package (in a
> convoluted way, I think; can't remember the details now). When I
> changed it so it did not, I had an email from someone saying he had
> missed a bunch of appointments.

-- 
Kim F. Storm  http://www.cua.dk

Re: bootstrap from scratch

[Jason Rumney]

Glenn Morris <gmorris+emacs@ast.cam.ac.uk> writes:

> Loading appt.el used to activate the appointment package (in a
> convoluted way, I think; can't remember the details now). When I
> changed it so it did not, I had an email from someone saying he had
> missed a bunch of appointments.
>
> So I had to make loading the package activate it, for "historical
> reasons".

Mail from one user does not seem to be a good reason to reintroduce
buggy behaviour. It has been the convention in Emacs for a long time
now that loading a package does not have side-effects.

Perhaps a better approach is to start a timer on load, and if appt is
not "activated" within a few seconds, then warn the user that loading
the package no longer activates it, and tell them the prefered way of
activating appt (usually via an autoloaded function).

Re: bootstrap from scratch [is now appt activation]

[Marcelo Toledo]

Jason Rumney <jasonr@gnu.org> writes:

> Perhaps a better approach is to start a timer on load, and if appt is
> not "activated" within a few seconds, then warn the user that loading
> the package no longer activates it, and tell them the prefered way of
> activating appt (usually via an autoloaded function).

Create a convention that it will not be activated when loaded and add
this information to important documents such as manuals, news, ... is
fine. Warning the user after loading the package doesn't seem
correct, imagine if he loads 10 packages that warn him of something. I
wouldn't like.

-- 
Marcelo Toledo
marcelo@marcelotoledo.org
http://www.marcelotoledo.org
Mobile: 55 71 9116-1101

Re: bootstrap from scratch [is now appt activation]

[Jason Rumney]

Marcelo Toledo <marcelo@marcelotoledo.org> writes:

> Create a convention that it will not be activated when loaded

That convention already exists.

> Warning the user after loading the package doesn't seem
> correct, imagine if he loads 10 packages that warn him of something.

I didn't mean to do that for all packages, just as an exception for
the case of appt, if changing the effect of loading it will cause
people to miss appointments, since it is not obvious that appt has not
been activated. Most packages already follow the above convention.

Re: bootstrap from scratch

[Richard Stallman]

    Perhaps a better approach is to start a timer on load, and if appt is
    not "activated" within a few seconds, then warn the user that loading
    the package no longer activates it, and tell them the prefered way of
    activating appt (usually via an autoloaded function).

This could be a good approach.  But I am not sure, because probably
most people that use this package activate it from the .emacs file.
If it works well in that case too, then it is good.

Re: bootstrap from scratch

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     Perhaps a better approach is to start a timer on load, and if appt is
>     not "activated" within a few seconds, then warn the user that loading
>     the package no longer activates it, and tell them the prefered way of
>     activating appt (usually via an autoloaded function).
>
> This could be a good approach.  But I am not sure, because probably
> most people that use this package activate it from the .emacs file.

That was why I suggested using a timer, to give the rest of .emacs
time to be processed.

Re: bootstrap from scratch

[Richard Stallman]

    > This could be a good approach.  But I am not sure, because probably
    > most people that use this package activate it from the .emacs file.

    That was why I suggested using a timer, to give the rest of .emacs
    time to be processed.

If it works well in that case too, it's a good solution.
Someone can try it.

Re: bootstrap from scratch

[Richard Stallman]

    As the comment says, it's necessary for backwards compatibility, and I
    wasn't particularly happy about having to do it.

Backwards compatibility is not sufficient reason for this.

    Loading appt.el used to activate the appointment package (in a
    convoluted way, I think; can't remember the details now). When I
    changed it so it did not, I had an email from someone saying he had
    missed a bunch of appointments.

He will just have to change his init file.  Please take this out now.

Re: bootstrap from scratch

[Glenn Morris]

Richard Stallman wrote:

> He will just have to change his init file.  Please take this out now.

Okay. Separately, I'll see if I can achieve backwards compatibility
some other way.

Re: bootstrap from scratch

[Glenn Morris]

Alan Shutko wrote:

> -(appt-activate 1)
> -
> +(if (not noninteractive)
> +    (appt-activate 1))


I think a better solution might be to make solar-setup barf if called
non-interactively, since it can't do anything in that case anyway. The
call to diary in appt.el is already in a condition-case, so the error
will just get ignored.

icalendar.el doesn't actually seem to need appt.el anyway...

Re: bootstrap from scratch

[Richard Stallman]

	    * calendar/appt.el: Only activate appt if in an interactive
	    session.  This stops appt from prompting during Emacs bootstrap.

Just loading appt.el probably should not activate the feature.
In the 90s it was not unusual for packages to work that way,
but when Custom was added it became common for a package to be
loaded simply because someone wanted to customize a variable.
So our convention, since then, is that just loading a package
shouldn't really change anything.

If appt doesn't follow this convention, we should change it to do so.

Re: bootstrap from scratch

[Richard Stallman]

    This is a conundrum: Any value that lets the compilation proceed will 
    (necessarily) produce wrong results.  Any value that stops the calculation if 
    the latitude/longitude/zone are not set will stop compilation.  Silly.

The value should not be used at compile time.

Re: bootstrap from scratch

[Marcelo Toledo]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Today, I removed *all* my Emacs' CVS sources using `rm -rf emacs' and
> checked out fresh sources.  The `59 Temple Place' zipcode is now
> correct.  My earlier report was based on a damaged set of sources.
> Please ignore it.
>
> Since I had new sources, I could configure and bootstrap build with a
> completely fresh CVS Emacs.
>
> The good news is that the bootstrap mostly worked.
> The bad news is that the bootstrap failed once.

It also failed for me, I think it was here:

(...)
Loading vc-hooks...
Loading jka-comp-hook (source)...
Attempt to autoload define-minor-mode while preparing to dump
make[1]: *** [emacs] Error 255
make[1]: Leaving directory `/home/marcelo/projetos/emacs/src'
make: *** [src] Error 2

but like you I've removed all my sources and checkout is timing out
right now, so I give details tomorow.
-- 
Marcelo Toledo
marcelo@marcelotoledo.org
http://www.marcelotoledo.org
Mobile: 55 71 9116-1101

Re: bootstrap from scratch

[Glenn Morris]

"Robert J. Chassell" wrote:

> The bad news is that the bootstrap failed once.
>
> One bug appeared when I used this command:
>
>      (progn
>        (cd "/usr/local/src/emacs/")
>        (compile
>         "./configure --with-type1 \
>          --with-x-toolkit=gtk \
>          --prefix=/usr/local --with-sound=yes \
>          && time make bootstrap"))
>
> During the build, compilation halted and I was asked to
>
>              "Enter longitude (decimal fraction; + east, - west): "
>
> which is a prompt from     emacs/lisp/calendar/solar.el

There have been no non-trivial changes to solar.el in over a year, so
this was a bit surprising.

I repeated your experiment. My bootstrap failed because the current
version of org.el has an extra parenthesis. Fixing that, and doing
everything from scratch, it all worked fine. org.el has references to
some of the calendar functions, including those for sunrise etc.
org.el has been changed a lot (comparatively) recently.

Conclusion: let's assume some transient weirdness (in org.el, or
someplace else). :)
No need to consider changing the default calendar lat/long any more.

Re: RMAIL, MIME-related bug

[Richard Stallman]

    Before loading rmime.el, you need to load charset.el, which is in a
    library from 1996 written by Juliusz Chroboczek <jec@dcs.ed.ac.uk>.

We don't have legal papers from Chroboczek.

    (For creating MIME messages, I use Marc Andreessen's mime-compose.el,
    which he wrote in 1992 before he started Netscape.)

We don't have papers for that either.

We would need to find them and ask them for papers
if we are to use this code.  Nonetheless, to compare
this and Morioka's package would be a useful activity.

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> Date: Sun, 12 Oct 2003 21:47:43 +0200 (CEST)
> From: Alexander Pohoyda <alexander.pohoyda@gmx.net>
> 
> When we convert the email to babyl format, we can do some MIME-related
> processing on it, for example: all text/* bodyparts may be
> transfer-encoding (quoted-printable and base64) decoded, PGP/GPG
> signatures verified, PGP/GPG decryption done, header fields of type
> =?...?B?...?= decoded (RFC 2047) and unfolded (RFC 2822), etc.
> This needs to be done once. No information is lost in this step. No
> structure information is lost either.

I agree that these are best done while converting to Babyl. 

> Granted, we can delete boundaries and header field we don't want to
> see, but what to do with big bodyparts like attached images?

We could replace them with some icon, and give the user a way to
decode and display them with some key binding.

> Also, please note that if we delete any MIME-related information, we
> will not be able to parse the message again later.

You don't need to delete it, just to hide it.  RMAIL already hides
some headers, so the same machinery could be used here.

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

> > Granted, we can delete boundaries and header field we don't want to
> > see, but what to do with big bodyparts like attached images?
> 
> We could replace them with some icon, and give the user a way to
> decode and display them with some key binding.

Replace on the screen, not changing the content of the mail, right?
That's what I would like to do. The problem is that we have to do this
after the mail is reformated, but there is no valid MIME message after
the rmail-reformat-message call: the message is broken into two parts
by the EOOH marker.
To be able to MIME-parse it, I have to glue the message back and
delete the "simplified" header in between.

> > Also, please note that if we delete any MIME-related information, we
> > will not be able to parse the message again later.
> 
> You don't need to delete it, just to hide it.  RMAIL already hides
> some headers, so the same machinery could be used here.

If you mean rmail-clear-headers function, then it does not hide headers,
but deletes them.

That's what I'm trying to hear in this discussion.
Can't we just hide header fields instead of creating another "simplified"
header in between of the message and thus braking it?

-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72
 15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Thien-Thi Nguyen]

"Alexander Pohoyda" <alexander.pohoyda@gmx.net> writes:

   That's what I'm trying to hear in this discussion.  Can't we just
   hide header fields instead of creating another "simplified" header in
   between of the message and thus braking it?

you have the right idea.  hiding is the desired functionality, and
currently, deleting is the implementation.  it's probably ok to keep the
functionality and choose a more desirable implementation (overlays, for
example).  then when someone complains about the change breaking their
code you can say "that was an implementation detail".  then, they will
of course ask you for your high-level design and API, in order to avoid
being burned in the future.  then, you will know you have thought about
things in the right way from the beginning.

thi

Re: RMAIL, MIME-related bug

[Thien-Thi Nguyen]

Thien-Thi Nguyen <ttn@glug.org> writes:

   currently, deleting is the implementation.
              ^^^^^^^^

oops, this should be some other gerund, like "copying".
i hope you understand anyway.

thi

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

>    That's what I'm trying to hear in this discussion.  Can't we just
>    hide header fields instead of creating another "simplified" header in
>    between of the message and thus braking it?
> 
> you have the right idea.  hiding is the desired functionality, and
> currently, deleting is the implementation.  it's probably ok to keep the
> functionality and choose a more desirable implementation (overlays, for
> example).  then when someone complains about the change breaking their
> code you can say "that was an implementation detail".  then, they will
> of course ask you for your high-level design and API, in order to avoid
> being burned in the future.  then, you will know you have thought about
> things in the right way from the beginning.

Sorry, but I do not understand what you propose here.
Not to change anything because it may brake some code?
I'm afraid you are right. Too much code may be based on current
implementation.

-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72
 15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Thien-Thi Nguyen]

   From: "Alexander Pohoyda" <alexander.pohoyda@gmx.net>
   Date: Thu, 16 Oct 2003 15:27:40 +0200 (MEST)

   Sorry, but I do not understand what you propose here.
   Not to change anything because it may brake some code?

no, that is an extreme position that is recognizably unworkable.
i am, instead, proposing you analyze the code from a two-level
perspective, the design level (high) and the implementation
level (low), and change the implementation while keeping the
design.

here, the design is relatively (in my mind as an RMAIL user)
straightforward: allow customization of which headers are
visible and their ordering.  to date, the implementation has
been a re-rendering (copying) of the desired-visible headers to
another block followed by narrowing to that block.  what new
implementation you choose should support the design as well as
any additional criteria that have arisen since the original
rmail.el was written (e.g., encoding issues).

   Too much code may be based on current implementation.

this is something we cannot know a priori.  but if we know the
nature of the changes to the implementation layer, we can help
fix those pieces of code that rely on it.

we can do this by either retargeting the broken code to the new
implementation or by retargeting the broken code to the design.
the latter is preferable since, if we do a good job, the design
will not change so much in the future whereas the implementation
may (or may not ;-).

thi

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> Date: Thu, 16 Oct 2003 09:41:26 +0200 (MEST)
> From: "Alexander Pohoyda" <alexander.pohoyda@gmx.net>
> 
> The problem is that we have to do this
> after the mail is reformated, but there is no valid MIME message after
> the rmail-reformat-message call: the message is broken into two parts
> by the EOOH marker.
> To be able to MIME-parse it, I have to glue the message back and
> delete the "simplified" header in between.

I don't understand why is it important to have the message in its
original pre-`rmail-reformat-message' form.  All the necessary MIME
information is still there, part of it before EOOH, part of it
after.  So you ought to be able to figure out how to process the
message, right?  What am I missing?

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

> > The problem is that we have to do this
> > after the mail is reformated, but there is no valid MIME message after
> > the rmail-reformat-message call: the message is broken into two parts
> > by the EOOH marker.
> > To be able to MIME-parse it, I have to glue the message back and
> > delete the "simplified" header in between.
> 
> I don't understand why is it important to have the message in its
> original pre-`rmail-reformat-message' form. 

Because, after reformatting it is not a MIME message anymore!

You agreed that we can do some mail processing before reformatting
and you agree that we have to do even more processing after reformatting.
Thus, if we want to use the same functions to do the job, we have to
teach them to ignore this "simplified" header. Now, MIME is recursive and
this means that we have to do this ignoring in every media type handler.
Is there anything we gain with this implementation?

OK, this may not be that important. I just don't see a reason why do we
have to reformat the message just to ignore this reformatting later.
Reformatting only introduces an obstacle. Why to do that?

And, as I mentioned before, I cannot re-use the old machinery (namely:
deleting header fields), thus header-field hiding will be necessary anyway.
So why not to hide header fields everywhere instead of deleting them
and reformatting the original message?


> All the necessary MIME information is still there, part of it before
> EOOH, part of it after. 

Yes, all information is there, but the structure is not.
The structure is broken. There is no MIME message anymore.

> So you ought to be able to figure out how to process the
> message, right?  What am I missing?

Right, everything is possible. The only question is: does it make sense?

In the end, if there is no other acceptable solution, I will have to do it
this way.

-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72
 15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> Date: Thu, 16 Oct 2003 15:14:55 +0200 (MEST)
> From: "Alexander Pohoyda" <alexander.pohoyda@gmx.net>
> 
> Because, after reformatting it is not a MIME message anymore!

So?  We are not sending that text as-is to any MTA, are we?  We are
just processing the text locally.  So we don't need to comply to MIME
standards, do we?

> OK, this may not be that important. I just don't see a reason why do we
> have to reformat the message just to ignore this reformatting later.
> Reformatting only introduces an obstacle. Why to do that?

I think it eases further processing elsewhere in RMAIL.  IIRC, many
RMAIL functions need to access the headers and the body separately.

Of course, it is also possible to avoid that reformatting, but then
your job will become much bigger, I think.

Re: RMAIL, MIME-related bug

[David Kastrup]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > Date: Thu, 16 Oct 2003 15:14:55 +0200 (MEST)
> > From: "Alexander Pohoyda" <alexander.pohoyda@gmx.net>
> > 
> > Because, after reformatting it is not a MIME message anymore!
> 
> So?  We are not sending that text as-is to any MTA, are we?

How about forwarding?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > Because, after reformatting it is not a MIME message anymore!
> 
> So?  We are not sending that text as-is to any MTA, are we?

No, I have never done that, but remember the problem with exporting
an email to the Unix mail file. Who knows how else we could use the
email would it be not reformatted.


> We are just processing the text locally. So we don't need to comply
> to MIME standards, do we?

Right, we don't have to, but why not to if that significantly
simplifies the processing?


> > OK, this may not be that important. I just don't see a reason why do we
> > have to reformat the message just to ignore this reformatting later.
> > Reformatting only introduces an obstacle. Why to do that?
> 
> I think it eases further processing elsewhere in RMAIL.

Who may know that for sure?


>                                                         IIRC, many
> RMAIL functions need to access the headers and the body separately.

No problems with that. I am not going to change it.


> Of course, it is also possible to avoid that reformatting, but then
> your job will become much bigger, I think.

Yes, I will have to modify some Rmail functions, but the result, I'm
sure, is well worth the effort.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> From: Alexander Pohoyda <alexander.pohoyda@gmx.net>
> Date: 16 Oct 2003 23:18:39 +0200
> 
> > > OK, this may not be that important. I just don't see a reason why do we
> > > have to reformat the message just to ignore this reformatting later.
> > > Reformatting only introduces an obstacle. Why to do that?
> > 
> > I think it eases further processing elsewhere in RMAIL.
> 
> Who may know that for sure?

I'd say look in the sources, it's quite clear from that.

Re: RMAIL, MIME-related bug

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 16 Oct 2003 13:20:48 +0200, Eli Zaretskii <eliz@elta.co.il> wrote:
>
> I don't understand why is it important to have the message in its
> original pre-`rmail-reformat-message' form.  All the necessary MIME
> information is still there, part of it before EOOH, part of it
> after.  So you ought to be able to figure out how to process the
> message, right?  What am I missing?

It is important if you wish to run external command on it. I use
metamail frequently on the mail buffer. With the  current `rmail' I
use the `rmail-edit-current-message' function to restore (almost) the
original message (it has the `x-Coding-System' line added and the
Mail-from: pseudo header prefixed).

Also, you need the mail in its "undisturbed" form, if you want to
resend it like a mail-relay (another function that I use a lot).

Ehud.


- --
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE/jqzpLFvTvpjqOY0RAsaZAJ9fQjCX/EfJiUj5XUGVOwqrw1MpCgCfQEEV
dRsVCG8KWmgC2B+h9fGicq8=
=5G08
-----END PGP SIGNATURE-----

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> Date: Thu, 16 Oct 2003 16:36:26 +0200
> From: "Ehud Karni" <ehud@unix.mvs.co.il>
> 
> It is important if you wish to run external command on it. I use
> metamail frequently on the mail buffer. With the  current `rmail' I
> use the `rmail-edit-current-message' function to restore (almost) the
> original message (it has the `x-Coding-System' line added and the
> Mail-from: pseudo header prefixed).

It is also decoded into the Emacs internal representation of
characters, so you don't have the original message anyway (unless it's
pure ASCII).

> Also, you need the mail in its "undisturbed" form, if you want to
> resend it like a mail-relay (another function that I use a lot).

That's why in the past discussions of this issue someone suggested to
redesign RMAIL along the lines of Gnus: leave the original message
alone, and produce the reformatted one in a separate buffer.  This is
actually the main reason I asked Alexander to take this discussion
here.  However, it sounds like Alexander has no intent to follow Gnus,
and no one else raised that problem either (until now).

Re: RMAIL, MIME-related bug

[Richard Stallman]

    If you mean rmail-clear-headers function, then it does not hide headers,
    but deletes them.

In the version of Rmail that uses mbox format, I believe it
makes unwanted header fields invisible.

Re: RMAIL, MIME-related bug

[Richard Stallman]

    > When we convert the email to babyl format,

Paul Riley and I have made a version of Rmail that doesn't use Babyl
format.  We want to get rid of it entirely.  I think it is currently
available in a branch called rmail-mbox-branch.

So please don't think in terms of conversion to Babyl
format when designing future Rmail changes.

						 we can do some MIME-related
    > processing on it, for example: all text/* bodyparts may be
    > transfer-encoding (quoted-printable and base64) decoded, PGP/GPG
    > signatures verified, PGP/GPG decryption done, header fields of type
    > =?...?B?...?= decoded (RFC 2047) and unfolded (RFC 2822), etc.
    > This needs to be done once. No information is lost in this step. No
    > structure information is lost either.

    I agree that these are best done while converting to Babyl. 

I disagree.  I don't want any decryption done and saved on my disk.
(You won't be able to do the decryption without asking me for my
passphrase, and I would not give it.)

Decoding of quoted-printable and base64 may cause problems too.  The
point of these encodings is so that the data can be unambiguously
included in a message.  If you decode it and store the result in the
Rmail file, that brings back the ambiguities these encodings were
designed to avoid.

    > All the necessary MIME information is still there, part of it before
    > EOOH, part of it after. 

    Yes, all information is there, but the structure is not.
    The structure is broken. There is no MIME message anymore.

It is not a good idea to make such drastic changes to the message as
it is saved on disk.  They should be done as part of displaying the
message, when the user selects it.  The results can be cached to make
moving between messages faster, if that's desirable.

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

> Paul Riley and I have made a version of Rmail that doesn't use Babyl
> format.  We want to get rid of it entirely.  I think it is currently
> available in a branch called rmail-mbox-branch.
> 
> So please don't think in terms of conversion to Babyl
> format when designing future Rmail changes.

Great! I'll be learning rmail-mbox-branch now and will come back
with new questions later.

Thanks to everybody for your ideas!


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 16 Oct 2003 19:06:49 -0400
> 
>     > When we convert the email to babyl format,
> 
> Paul Riley and I have made a version of Rmail that doesn't use Babyl
> format.  We want to get rid of it entirely.  I think it is currently
> available in a branch called rmail-mbox-branch.
> 
> So please don't think in terms of conversion to Babyl
> format when designing future Rmail changes.

There still is a phase where the messages are processed for display,
right?  At the very least, the modified RMAIL should find the
boundaries of each message and narrow the buffer to those boundaries,
right?  That's the phase I was referring to, the "conversion to Babyl"
is just a convenient name for it, nothing more.

Re: RMAIL, MIME-related bug

[Stefan Monnier]

> When we convert the email to babyl format, we can do some MIME-related
> processing on it, for example: all text/* bodyparts may be
> transfer-encoding (quoted-printable and base64) decoded, PGP/GPG
> signatures verified, PGP/GPG decryption done, header fields of type
> =?...?B?...?= decoded (RFC 2047) and unfolded (RFC 2822), etc.
> This needs to be done once. No information is lost in this step. No
> structure information is lost either.

In order not to lose information, you need to keep the GPG signatures you
have just verified since you can't re-create them yourself.  Of course, you
also need to keep the signed-text unless you're super-extra-careful to make
sure that you can re-create the exact same byte-sequence from the rest of
the data, which is rather unlikely.

Why do people even consider doing any processing at that point?
The processing should be done for display and nothing else, because any
other option will make you lose information at some point and also forces
you to have code to re-create the original format, whereas the "display-side
processing" approach only needs to parse MIME but never needs to
re-construct it.


        Stefan

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: 16 Oct 2003 12:54:24 -0400
> 
> Why do people even consider doing any processing at that point?

Because doing that when the user wants to display a message means that
(a) displaying a message will be slow, and (b) you will need to do
this kind of processing every time you display a message.  In
contrast, the current design of RMAIL does the processing only once
for each message.

> any other option will make you lose information at some point and
> also forces you to have code to re-create the original format

The question is, do we care that we lose information, and do we need
to recreate the original format?  That's exactly what I was asking
Alexander to explain.

Re: RMAIL, MIME-related bug

[Stefan Monnier]

> The question is, do we care that we lose information, and do we need
> to recreate the original format?  That's exactly what I was asking
> Alexander to explain.

I need to be able to forward/resend a GPG-signed message (or a message with
a GPG-signed subpart), so at least in those cases we need to preserve all
the information.


        Stefan


PS: All the MUAs I know do the processing upon display, so I don't
    understand why it would pose any performance problem.

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: 16 Oct 2003 14:49:13 -0400
> 
> I need to be able to forward/resend a GPG-signed message (or a message with
> a GPG-signed subpart), so at least in those cases we need to preserve all
> the information.

Is forwarding such a frequent operation?

> PS: All the MUAs I know do the processing upon display, so I don't
>     understand why it would pose any performance problem.

It simply sounds sub-optimal to do the decoding every time the message
is displayed.

Re: RMAIL, MIME-related bug

[Stefan Monnier]

>> I need to be able to forward/resend a GPG-signed message (or a message with
>> a GPG-signed subpart), so at least in those cases we need to preserve all
>> the information.
> Is forwarding such a frequent operation?

The question is not even relevant: it needs to be possible to do it,
so you need to keep the info, just in case.

>> PS: All the MUAs I know do the processing upon display, so I don't
>> understand why it would pose any performance problem.
> It simply sounds sub-optimal to do the decoding every time the message
> is displayed.

It might be suboptimal in some cases, but in terms of programmer resources,
it's pretty close to optimal.  Admittedly, it's not clear whether programmer
resources is the bottleneck w.r.t MIME decoding given the number of
different MIME-decoding package have been written in elisp.  Or maybe it is
the bottleneck and it's a shame that we would write yet-another one rather
than use a pre-existing one such as the one in Gnus (wisely used by MH-E).


        Stefan

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: 16 Oct 2003 15:21:40 -0400
> 
> > Is forwarding such a frequent operation?
> 
> The question is not even relevant: it needs to be possible to do it,
> so you need to keep the info, just in case.

If the operation is not frequent, the information can be kept in some
form that doesn't allow an efficient implementation.  So the question
is relevant.

> It might be suboptimal in some cases, but in terms of programmer resources,
> it's pretty close to optimal.  Admittedly, it's not clear whether programmer
> resources is the bottleneck w.r.t MIME decoding given the number of
> different MIME-decoding package have been written in elisp.  Or maybe it is
> the bottleneck and it's a shame that we would write yet-another one rather
> than use a pre-existing one such as the one in Gnus (wisely used by MH-E).

Actually, I think it's a shame that every add-on mail package invented
its own way of doing things instead of contributing the infrastructure
to Emacs.  If they did it the Right Way, we would not need to have
this discussion now, just point Alexander to the existing functions.

Re: RMAIL, MIME-related bug

[Stephen J. Turnbull]

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

    Eli> Actually, I think it's a shame that every add-on mail package
    Eli> invented its own way of doing things instead of contributing
    Eli> the infrastructure to Emacs.  If they did it the Right Way,
    Eli> we would not need to have this discussion now, just point
    Eli> Alexander to the existing functions.

What do you think tm and SEMI are?


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 17 Oct 2003 20:54:34 +0900
> 
> What do you think tm and SEMI are?

I don't know.  They aren't part of Emacs, so I couldn't possibly mean
them.

Re: RMAIL, MIME-related bug

[Stephen J. Turnbull]

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

    >> From: "Stephen J. Turnbull" <stephen@xemacs.org> Date: Fri, 17
    >> Oct 2003 20:54:34 +0900

    >> What do you think tm and SEMI are?

    Eli> I don't know.  They aren't part of Emacs, so I couldn't
    Eli> possibly mean them.

I know.  The question is why aren't they?  SEMI is semi-encumbered
(the same legal issues that prevented Mule from being assigned to the
FSF), but tm (SEMI's predecessor) was written when Tomohiko Morioka
was a student, dating back to 1995 or so.  He told me that he
certainly hoped they would be distributed with Emacs and XEmacs.  I
don't know why Emacs never bothered to pick them up; I'm sure Tomo
would have signed an assignment, and SEMI could have been picked up
more or less "for free" along with Mule since it was done by Tomo
while he was employed at ETL AFAIK.

The VM libraries were written at a time when Emacs didn't support
images or audio, and Mule had been explicitly rejected.  It simply
wasn't possible to contribute them to Emacs, as they would have been
meaningless.  (Of course Kyle would never sign an assignment, but even
if Kyle would, it would have been useless effort to support FSF GNU
Emacs then.  NB: There were GNU Emacsen being distributed with the
Mule patch, and vm supported those, as it supports GNU Emacs today.)

w3.el's MIME support was also explicitly oriented toward Emacsen with
internal multimedia support.

So we come to Gnus.  The Gnus libraries were written post-Mule, with
generality clearly in mind, and will be included with Emacs in the
future.  MH-E clearly made the right decision in picking them as the
basis for its own MIME support.

So I don't see what your problem is.  Emacs's lack of a generic MIME
library seems to be just another of the tradeoffs that have to be made
in world with limited resources.  I think it was a mistake, but that's
20-20 hindsight.  In any case the lack of a generic MIME library will
soon be corrected, except that vm probably will continue to use its
idiosyncratic libraries for its own idiosyncratic reasons.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: RMAIL, MIME-related bug

[Simon Josefsson]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:
>
>     >> From: "Stephen J. Turnbull" <stephen@xemacs.org> Date: Fri, 17
>     >> Oct 2003 20:54:34 +0900
>
>     >> What do you think tm and SEMI are?
>
>     Eli> I don't know.  They aren't part of Emacs, so I couldn't
>     Eli> possibly mean them.
>
> I know.  The question is why aren't they?

Wasn't tm abandoned 1998 or so?  I hope that some parts of SEMI that
we managed to get copyright papers for, will be moving into Emacs as
part of Gnus.  For example PGG (part of Gnus 5.10) and SASL (hopefully
will be part of the next development cycle of Gnus).  The main problem
with SEMI code is that it is assumes APEL.

Generally, I'm not sure there is much in tm/SEMI that is not already
supported by Emacs, via Gnus or some other package.  Do you have
example of some practical benefit (i.e., feature-wise, visible to
users) adding SEMI to Emacs actually would have?

Re: RMAIL, MIME-related bug

[Stephen J. Turnbull]

>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes:

    Simon> Wasn't tm abandoned 1998 or so?

Yes.

    Simon> Do you have example of some practical benefit (i.e.,
    Simon> feature-wise, visible to users) adding SEMI to Emacs
    Simon> actually would have?

Not any more.  Eli was remarking that a lot of duplicate effort could
have been avoided if there were a standard MIME library.  AFAIK, tm
was on offer in 1996-97, but nobody did anything about it.  Ditto SEMI
in '97-99.  Unfortunate lack of foresight, that's all.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: RMAIL, MIME-related bug

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Not any more.  Eli was remarking that a lot of duplicate effort could
> have been avoided if there were a standard MIME library.  AFAIK, tm
> was on offer in 1996-97, but nobody did anything about it.  Ditto SEMI
> in '97-99.  Unfortunate lack of foresight, that's all.

Well, yes and no.  When I started working on the MIME library for
Gnus, I had intended using SEMI.  However, that proved rather
difficult due to how SEMI was designed: It isn't (or wasn't at that
time) structured anything like a library.  Instead, it worked by
redefining functions/hooks in the packages it supported.  You'd
basically require the relevant SEMI packages, and Gnus/rmail/whatever
would suddenly become MIME capable.

That's a perfectly valid approach if you intend being an add-on
package with no cooperation from the packages you support, but it
makes it rather difficult to maintain things and integrate things in
a more user-friendly (and customizable) fashion.

I spent about a week looking at SEMI and trying to pick stuff out of
it, but in the end I gave up and started writing things (basically)
from scratch.

I may be misremembering, but I think Kyle went through a similar
process about the same time with vm. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: RMAIL, MIME-related bug

[Richard Stallman]

    I know.  The question is why aren't they?  SEMI is semi-encumbered
    (the same legal issues that prevented Mule from being assigned to the
    FSF),

What specifically is the problem?  If it is work done at ETL, that
may not really be a problem.  Since we accepted their Mule code,
we can accept some more with no difficulty.

I think we intended to install SEMI, but the work of integrating
it never got done.

Now we have the option of using SEMI or adopting the Gnus code.  To
make that decision, someone who knows Emacs Lisp well and is not
already a partisan of either one should study them both and compare
them.  Is there someone who would like to do that?

Re: RMAIL, MIME-related bug

[Stephen J. Turnbull]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

    rms> What specifically is the problem?  If it is work done at ETL,
    rms> that may not really be a problem.  Since we accepted their
    rms> Mule code, we can accept some more with no difficulty.

That is exactly what I meant; it's just that at the time that SEMI was
being developed, Mule had not yet been accepted into Emacs.  I don't
think there are any problems now (except that Morioka-san's current
employer, the University of Kyoto, probably has an interest in more
recently developed code).


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: RMAIL, MIME-related bug

[Kenichi Handa]

In article <E1ACFFL-0004gm-Pm@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>     I know.  The question is why aren't they?  SEMI is semi-encumbered
>     (the same legal issues that prevented Mule from being assigned to the
>     FSF),

> What specifically is the problem?  If it is work done at ETL, that
> may not really be a problem.  Since we accepted their Mule code,
> we can accept some more with no difficulty.

Although Morioka-san, the main programmer of SEMI, stayed at
ETL for one year, ETL is not a copyright holder of SEMI.  We
already have assignment papers from the developpers, but
that was several years ago.  I don't know how many other
programers contributed code to the current SEMI, FLIM, and
APEL (three cooperating packages).

I included Morioka-san's address in CC:.  Morioka-san,
please give us the information about the current status of
those packages.  Does the assignment papers already sent to
FSF cover the whole codes (except tiny changes)?  If not, is
it possible to get papers from the other programmers?  FYI,
you can read previous mails of this thread at:
	http://mail.gnu.org/archive/html/emacs-devel/

---
Ken'ichi HANDA
handa@m17n.org

> I think we intended to install SEMI, but the work of integrating
> it never got done.

> Now we have the option of using SEMI or adopting the Gnus code.  To
> make that decision, someone who knows Emacs Lisp well and is not
> already a partisan of either one should study them both and compare
> them.  Is there someone who would like to do that?

Re: RMAIL, MIME-related bug

[守岡知彦 / MORIOKA Tomohiko]

>>>>> In <200310221052.TAA08319@etlken.m17n.org> 
>>>>>	"Kenichi" = Kenichi Handa <handa@m17n.org> wrote:

Kenichi> I included Morioka-san's address in CC:.  Morioka-san,
Kenichi> please give us the information about the current status of
Kenichi> those packages.  Does the assignment papers already sent to
Kenichi> FSF cover the whole codes (except tiny changes)?  If not, is
Kenichi> it possible to get papers from the other programmers?  FYI,
Kenichi> you can read previous mails of this thread at:
Kenichi> 	http://mail.gnu.org/archive/html/emacs-devel/

I've rearranged APEL/FLIM/SEMI to merge into GNU Emacs in 2000--2002.
The result is available via anonymous CVS:

    % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root login
    CVS password: [CR] # NULL string 

    % cvs -z9 -d :pserver:anonymous@cvs.m17n.org:/cvs/root co lemi

SEMI related codes included in LEMI is already covered by assignment
papers.

-- 
tomo.

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

> Now we have the option of using SEMI or adopting the Gnus code.  To
> make that decision, someone who knows Emacs Lisp well and is not
> already a partisan of either one should study them both and compare
> them.  Is there someone who would like to do that?

Where can I get SEMI?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Lars Magne Ingebrigtsen]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> Where can I get SEMI?

<URL: http://emacs-21.ki.nu/application/semi.html> has the latest
versions of SEMI/APEL/FLIM, I think, but I might be wrong about that. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: RMAIL, MIME-related bug

[Kenichi Handa]

In article <87smllb370.fsf@oak.pohoyda.family>, Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> Where can I get SEMI?

Please try these ftp directories.

ftp://ftp.m17.org/pub/mule/semi/
ftp://ftp.m17.org/pub/mule/flim/
ftp://ftp.m17.org/pub/mule/apel/

---
Ken'ichi HANDA
handa@m17n.org

Re: RMAIL, MIME-related bug

[Satyaki Das]

Eli Zaretskii <eliz@elta.co.il> writes:

> Actually, I think it's a shame that every add-on mail package invented
> its own way of doing things instead of contributing the infrastructure
> to Emacs.  If they did it the Right Way, we would not need to have
> this discussion now, just point Alexander to the existing functions.

I don't know about "Right Way", but one way would be to call the
`mm-dissect-buffer' function found in mm-decode.el.

Satyaki

Re: RMAIL, MIME-related bug

[Lars Magne Ingebrigtsen]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> Actually, I think it's a shame that every add-on mail package invented
> its own way of doing things instead of contributing the infrastructure
> to Emacs.  If they did it the Right Way, we would not need to have
> this discussion now, just point Alexander to the existing functions.

The MIME library developed for Gnus was designed as a general-purpose
Emacs MIME library.  (Which is why it's documented in the Emacs-MIME
manual.) 

Some Gnus stuff has crept into the libraries, but that should be
fixable.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 17 Oct 2003 20:57:46 +0200
> 
> The MIME library developed for Gnus was designed as a general-purpose
> Emacs MIME library.

With all due respect, ``designed as'' is not the same as ``is''.  As
long as a library is not sent upstream to the Emacs maintainers and is
not described in the ELisp manual, it cannot be considered part of
Emacs infrastructure, in my opinion.

> (Which is why it's documented in the Emacs-MIME manual.)

That's a separate manual, not part of the ELisp manual.  Therefore, a
programmer who is looking for infrastructure that's part of Emacs will
not find this library.

In other words, a general-purpose library should not be part of a
package that is maintained outside Emacs.  IMHO, of course; YMMV.

Re: RMAIL, MIME-related bug

[Richard Stallman]

    With all due respect, ``designed as'' is not the same as ``is''.  As
    long as a library is not sent upstream to the Emacs maintainers and is
    not described in the ELisp manual, it cannot be considered part of
    Emacs infrastructure, in my opinion.

That is not our policy.  Something can be in a separate manual
and be a recommended part of Emacs facilities.

We typically do not document specialized Emacs libraries in the Emacs
Lisp manual, because it isn't useful to print the info about them on
paper.  We certainly would not document a MIME library in the Emacs
Lisp manual, because it is useful only for mail readers, and that is
too specialized.  That doesn't mean it isn't part of the standard
Emacs infrastructure.

However, it needs to be maintained in the Emacs CVS repository
if we are going to depend on it.

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 18 Oct 2003 19:05:29 -0400
> 
> Something can be in a separate manual and be a recommended part of
> Emacs facilities.

I don't think it ever worked in practice (not the recommendation
part--that's easy--but the actual use part).  Do you have any
examples?

> We certainly would not document a MIME library in the Emacs Lisp
> manual, because it is useful only for mail readers, and that is too
> specialized.

It is no less specialized than primitives like base64-decode-region.

Re: RMAIL, MIME-related bug

[Alex Schroeder]

Eli Zaretskii <eliz@elta.co.il> writes:

> I don't think it ever worked in practice (not the recommendation
> part--that's easy--but the actual use part).  Do you have any
> examples?

I've used the widget library before (ie. outside of custom).

Alex.
-- 
http://www.emacswiki.org/alex/
There is no substitute for experience.

Re: RMAIL, MIME-related bug

[Richard Stallman]

    > We certainly would not document a MIME library in the Emacs Lisp
    > manual, because it is useful only for mail readers, and that is too
    > specialized.

    It is no less specialized than primitives like base64-decode-region.

Those are primitives, and they are simple to document.

Anyway, I'm just telling you what our policy is.  Not every Emacs Lisp
facility has to be documented in the Emacs Lisp manual.

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     > We certainly would not document a MIME library in the Emacs Lisp
>     > manual, because it is useful only for mail readers, and that is too
>     > specialized.
> 
>     It is no less specialized than primitives like base64-decode-region.
> 
> Those are primitives, and they are simple to document.
> 
> Anyway, I'm just telling you what our policy is.  Not every Emacs Lisp
> facility has to be documented in the Emacs Lisp manual.

After I implemented it myself, I have found 2 more implementations of
quoted-printable primitives in Emacs/lisp tree.
Guess why? Because "Describe function" had no idea that they are
already implemented and I haven't found them in Emacs Lisp manual.

Would I even found them at the beginning, I would not dare to use the
one from Gnus, because:
* it belongs to different project in my eyes.
* gnus/qp.el requires mm-util, which I neither need nor want right now.

base64 functions are built-in, though.


2Lars: Only first 7 lines of the References header field are
highlighted in Gnus v5.9.0 and sorry, if this is already fixed.

-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Lars Magne Ingebrigtsen]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> After I implemented it myself, I have found 2 more implementations of
> quoted-printable primitives in Emacs/lisp tree.

Where did the second implementation live?

> Guess why? Because "Describe function" had no idea that they are
> already implemented and I haven't found them in Emacs Lisp manual.

Well, ok, but I find it somewhat puzzling that anybody would think
that Emacs didn't have something as basic as qp en/decoding somewhere
in its vast mass.

> Would I even found them at the beginning, I would not dare to use the
> one from Gnus, because:
> * it belongs to different project in my eyes.
> * gnus/qp.el requires mm-util, which I neither need nor want right now.

I think a better solution than writing yet another implementation
would be to move gnus/qp.el to mime/qp.el, and remove the
dependencies on mm-util (which is basically a compatibility library
between a bewildering array of X/Emacs versions).

> 2Lars: Only first 7 lines of the References header field are
> highlighted in Gnus v5.9.0 and sorry, if this is already fixed.

You mean in Message?  That's handled by font-lock, which has a
tendency to stop highlighting extremely long lines after a certain
point.  I'm sure it's customizable.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > After I implemented it myself, I have found 2 more implementations
> > of quoted-printable primitives in Emacs/lisp tree.
> Where did the second implementation live?

mail/rmail.el, rmail-decode-quoted-printable function.

I'd be very thankful if you merge them. Also, could we please agree
that these functions should return the size of en/de-coded text, the
same way as their base64-... counterparts?


> > Guess why? Because "Describe function" had no idea that they are
> > already implemented and I haven't found them in Emacs Lisp
> > manual. 
> Well, ok, but I find it somewhat puzzling that anybody would think
> that Emacs didn't have something as basic as qp en/decoding
> somewhere in its vast mass.

I was easily able to locate base64, thus the absence of
quoted-printable in base installation made me believe that it was
intentionally left out.


> > Would I even found them at the beginning, I would not dare to use
> > the one from Gnus, because:
> > * it belongs to different project in my eyes.
> > * gnus/qp.el requires mm-util, which I neither need nor want right
> > now. 
> I think a better solution than writing yet another implementation
> would be to move gnus/qp.el to mime/qp.el, and remove the

Why not mail/qp.el instead? The mime/ directory is going to be quite
empty :-)


> > 2Lars: Only first 7 lines of the References header field are
> > highlighted in Gnus v5.9.0 and sorry, if this is already fixed.
> You mean in Message?  That's handled by font-lock, which has a
> tendency to stop highlighting extremely long lines after a certain
> point.  I'm sure it's customizable.  :-)

Indeed. Thank you! :-)


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Richard Stallman]

    > Would I even found them at the beginning, I would not dare to use the
    > one from Gnus, because:
    > * it belongs to different project in my eyes.
    > * gnus/qp.el requires mm-util, which I neither need nor want right now.

    I think a better solution than writing yet another implementation
    would be to move gnus/qp.el to mime/qp.el,

We already have functions to do this in mailutils, so we
should standardize on those, unless the other set has some
advantage that would be an argument for preferring them.

Merging quoted-printable functions

[Alexander Pohoyda]

I'm trying to merge three implementations of quoted-printable
routines.

1. mail/mail-utils.el
   mail-(un)quote-printable (string)

2. gnus/qp.el
   quoted-printable-{en,de}code-{region|string}

3. mail/rmail.el
   rmail-decode-quoted-printable (region)


I would like to move GNUS functions into mail/mail-utils.el, because
they seem to be the best.
I would not like to append the mail- prefix, though. Is this OK?

Also, I would like quoted-printable-...-region functions to return the
resulting size, as their base64-...-region analogs do.

Any comments? Thank you.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: Merging quoted-printable functions

[Richard Stallman]

    3. mail/rmail.el
       rmail-decode-quoted-printable (region)

I just wrote some code (which I am not sure how to check in)
to get rid of that.  If you want to install before I can,
feel free.

    1. mail/mail-utils.el
       mail-(un)quote-printable (string)

    2. gnus/qp.el
       quoted-printable-{en,de}code-{region|string}

Merging these into one is a good idea.  If the one you choose
is the code from gnus/qp.el, let's move it to directory mail/.

    I would not like to append the mail- prefix, though. Is this OK?

Ok.

Can you preserve the old names in mail-... as aliases or trivial
interfaces to the new functions?

    Also, I would like quoted-printable-...-region functions to return the
    resulting size, as their base64-...-region analogs do.

That can't break anything, so no reason why not.

Re: RMAIL, MIME-related bug

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 16 Oct 2003 20:58:28 +0200, Eli Zaretskii <eliz@elta.co.il> wrote:
>
> > I need to be able to forward/resend a GPG-signed message (or a message with
> > a GPG-signed subpart), so at least in those cases we need to preserve all
> > the information.
>
> Is forwarding such a frequent operation?

Yes, I do 2-5 resends a day. I even wrote my own resend function to do
it like a mail relay, so only 1 received header is added and if the
new recipient mail transport agent will return the mail, it will go to
the originator of the mail.

Ehud.


- --
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE/jvKCLFvTvpjqOY0RAm7+AJ9jZoiSBEjGUJ5pm78eU4ZmmiXM7ACfTl/U
VGRgqh93ZwcfF9TmLk7Pygs=
=ASP5
-----END PGP SIGNATURE-----

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> Date: Thu, 16 Oct 2003 21:33:22 +0200
> From: "Ehud Karni" <ehud@unix.mvs.co.il>
> >
> > Is forwarding such a frequent operation?
> 
> Yes, I do 2-5 resends a day.

I almost never forward a message, let alone one with MIME attachments.

Re: RMAIL, MIME-related bug

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16 Oct 2003 14:49:13 -0400, Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:
>
> > The question is, do we care that we lose information, and do we need
> > to recreate the original format?  That's exactly what I was asking
> > Alexander to explain.
>
> I need to be able to forward/resend a GPG-signed message (or a message with
> a GPG-signed subpart), so at least in those cases we need to preserve all
> the information.

I second Stefan opinion. I just checked current RMAIL behavior. When
you do rmail edit (i.e. rmail-edit-current-message) it fully restores
the original mail including the original character encoding (I checked
it on a problematic Hebrew encoded in utf-8).

> PS: All the MUAs I know do the processing upon display, so I don't
>     understand why it would pose any performance problem.

I agree on this point too (only few mails are read more than once).

Ehud.


- --
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE/ju4ZLFvTvpjqOY0RAjgkAJ99A7/T4aSpAFQLeFzsmjoD7dbLaACfdSYc
SUy/Z7U3LG+mHarpzQoG4TE=
=/Ytc
-----END PGP SIGNATURE-----

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

> > > The question is, do we care that we lose information, and do we need
> > > to recreate the original format?  That's exactly what I was asking
> > > Alexander to explain.
> >
> > I need to be able to forward/resend a GPG-signed message (or a message with
> > a GPG-signed subpart), so at least in those cases we need to preserve all
> > the information.
> 
> I second Stefan opinion. I just checked current RMAIL behavior. When
> you do rmail edit (i.e. rmail-edit-current-message) it fully restores
> the original mail including the original character encoding (I checked
> it on a problematic Hebrew encoded in utf-8).

And if the message was sent base64 or quoted-printable -encoded?


> > PS: All the MUAs I know do the processing upon display, so I don't
> >     understand why it would pose any performance problem.
> 
> I agree on this point too (only few mails are read more than once).

I disagree here. I store emails and sometimes have to read them many
times. Not to mention summary-navigation.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16 Oct 2003 23:56:50 +0200, Alexander Pohoyda <alexander.pohoyda@gmx.net> wrote:
>
> > I second Stefan opinion. I just checked current RMAIL behavior. When
> > you do rmail edit (i.e. rmail-edit-current-message) it fully restores
> > the original mail including the original character encoding (I checked
> > it on a problematic Hebrew encoded in utf-8).
>
> And if the message was sent base64 or quoted-printable -encoded?

Neither. It was sent as 8 bit text. Here are the headers:

  Content-Type: text/plain; charset=UTF-8; format=flowed
  Content-Transfer-Encoding: 8bit


> > I agree on this point too (only few mails are read more than once).
>
> I disagree here. I store emails and sometimes have to read them many
> times. Not to mention summary-navigation.

I store email too, but still I say that only few are read more than
once. What summary navigation has to with it ? On other mail readers
the summary (index) is stored on a separate file altogether.

Ehud.


- --
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE/jxnpLFvTvpjqOY0RAoxkAJoDcIN11nTbQ+CgDBygSbJjKy+2VQCeJHeX
7Ff6oTbSRF6rWCFE2VbcVTQ=
=qE/4
-----END PGP SIGNATURE-----

Re: RMAIL, MIME-related bug

[Luc Teirlinck]

Ehud Karni wrote:

   I store email too, but still I say that only few are read more than
   once. What summary navigation has to with it ?

In RMAIL, with a summary buffer and an RMAIL buffer in another window,
C-p and C-n in the summary buffer update the message shown in the
RMAIL buffer.  The MIME decoding should be fast enough not to
excessively slow down C-n and C-p in the summary buffer.  It should
also be fast enough not to excessively slow down `n' and `p' in the
RMAIL buffer itself, which I would guess to be pretty much equivalent
(in that sense, "_summary_ navigation" is not the main problem,
navigation _in whatever form_ is.)

Whether I use C-n or C-p in the summary buffer or `n' or `p' in RMAIL,
I would wind up MIME decoding every message I do not immediately
delete several times, just by navigation.  That makes speed of MIME
decoding more relevant than it would otherwise be. As Richard pointed
out, however:

   It is not a good idea to make such drastic changes to the message as
   it is saved on disk.  They should be done as part of displaying the
   message, when the user selects it.  The results can be cached to make
   moving between messages faster, if that's desirable.

Whether caching would be desirable depends, of course, on how fast
MIME decoding without caching winds up being.

Sincerely,

Luc.

Re: RMAIL, MIME-related bug

[Kenichi Handa]

In article <200310162348.h9GNmZm25160@raven.dms.auburn.edu>, Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> Ehud Karni wrote:
>    I store email too, but still I say that only few are read more than
>    once. What summary navigation has to with it ?

> In RMAIL, with a summary buffer and an RMAIL buffer in another window,
> C-p and C-n in the summary buffer update the message shown in the
> RMAIL buffer.  The MIME decoding should be fast enough not to
> excessively slow down C-n and C-p in the summary buffer.  It should
> also be fast enough not to excessively slow down `n' and `p' in the
> RMAIL buffer itself, which I would guess to be pretty much equivalent
> (in that sense, "_summary_ navigation" is not the main problem,
> navigation _in whatever form_ is.)

One more point about efficiency is rmail-search and
rmail-search-backwards.  I can wait for a while just after I
type M-x rmail or g in RMAIL buffer.  But, I won't be able
to stand slowdown of those search operations.

I think this kind of method is ideal.

(1) Read RMAIL file without decoding into some hidden source
    buffer (unibyte).  It may be ok to process only
    Content-Transfer-Encoding.
(2) Prepare a view buffer.
(3) Insert the current message in the view buffer after decoding it.
(4) A background process (run by idle timer?) decodes not
    yet decoded message into the view buffer (like
    jit-lock-stealth-fontify).

While decoding, keep such big embeded data as images and
*.tar.gz in the source buffer, and embed buttons or
something in the view buffer.  Ignoreable headers are as
well.  Then, although we have double buffers source and
view, the latter won't become that big because it contains
only text.

We don't have to decode spam-like messages (detected
somehow) correctly, instead just insert "Perhaps this
message is a spam" in the view buffer, and allow users to
click it if they really want to see a decoded message.

But, it seems that it is a faily complicated work to
implement such a mechanism.

---
Ken'ichi HANDA
handa@m17n.org

Re: RMAIL, MIME-related bug

[Peter S Galbraith]

Eli Zaretskii <eliz@elta.co.il> wrote:

> > From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> > Date: 16 Oct 2003 12:54:24 -0400
> > 
> > Why do people even consider doing any processing at that point?
> 
> Because doing that when the user wants to display a message means that
> (a) displaying a message will be slow, and (b) you will need to do
> this kind of processing every time you display a message.  In
> contrast, the current design of RMAIL does the processing only once
> for each message.

Excuse the intrusion of a lurker...

Why would it be slow?  Try MH-E.  It re-does all MIME processing at
every display and it's quite fast.
 
> > any other option will make you lose information at some point and
> > also forces you to have code to re-create the original format
> 
> The question is, do we care that we lose information, and do we need
> to recreate the original format?  That's exactly what I was asking
> Alexander to explain.

For one, you can't check a GPG signature if you change one bit.
Secondly, it's much easier to convert your mail to some other MUA if it
left it intact.

We came up against similar questions working on MH-E, so I'm speaking
from some experience.

Best regards,
Peter

Re: RMAIL, MIME-related bug

[Peter S Galbraith]

Eli Zaretskii <eliz@elta.co.il> wrote:

> > From: Stefan Monnier <monnier@IRO.UMontreal.CA>

> > It might be suboptimal in some cases, but in terms of programmer
> > resources, it's pretty close to optimal.  Admittedly, it's not clear
> > whether programmer resources is the bottleneck w.r.t MIME decoding
> > given the number of different MIME-decoding package have been
> > written in elisp.  Or maybe it is the bottleneck and it's a shame
> > that we would write yet-another one rather than use a pre-existing
> > one such as the one in Gnus (wisely used by MH-E).
> 
> Actually, I think it's a shame that every add-on mail package invented
> its own way of doing things instead of contributing the infrastructure
> to Emacs. 

I'm not sure what you say is so true.

 wanderlust -> uses SEMI or tm.
 mew -> ?
 gnus -> implemented their own.
 MH-E -> uses gnus.

I see two major implemenations, and from the little I know the gnus and
FLIM/SEMI camps have a complicated history.  There are still many files
in common between the two.

When we started doing MIME in MH-E, we briefly looked at semi.  I had
trouble making heads or tails of it (my own limitations; the Japanese
web sites didn't help since I couldn't understand them) and since it's
not part of Emacs we would have had to get it to be part of Emacs before
we could use in MH-E.  So we took the gnus route.  We were lucky that
Satyaki Das was familiar with gnus, and he did the vast majority of the
MIME work.

>            If they did it the Right Way, we would not need to have
> this discussion now, just point Alexander to the existing functions.

The only MIME functions currently in Emacs are from gnus, so point him
at those.  Then all three MUAs in Emacs (rmail, gnus, MH-E) will be
using the same thing.  Or you drop rmail and start using MH-E (Okay,
just kidding!).

Peter

-- 
Peter S. Galbraith, MH-E developer  <p.galbraith@globetrotter.net>
GPG key 1024/D2A913A1 - 97CE 866F F579 96EE  6E68 8170 35FF 799E
6623'rd GNU/Linux user at the Counter - http://counter.li.org/

Re: RMAIL, MIME-related bug

[Stefan Monnier]

>> Actually, I think it's a shame that every add-on mail package invented
>> its own way of doing things instead of contributing the infrastructure
>> to Emacs. 

> I'm not sure what you say is so true.

>  wanderlust -> uses SEMI or tm.
>  mew -> ?
>  gnus -> implemented their own.
>  MH-E -> uses gnus.

He was probably also thinking of rmime.el, etach.el, VM, ...


        Stefan

Re: RMAIL, MIME-related bug

[Peter S Galbraith]

Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

> >> Actually, I think it's a shame that every add-on mail package invented
> >> its own way of doing things instead of contributing the infrastructure
> >> to Emacs. 
> 
> > I'm not sure what you say is so true.
> 
> >  wanderlust -> uses SEMI or tm.
> >  mew -> ?
> >  gnus -> implemented their own.
> >  MH-E -> uses gnus.
> 
> He was probably also thinking of rmime.el, etach.el, VM, ...
> 
> 
>         Stefan

Ah, forgive my ignorance.  I knew of VM (but have never tried it)
and have never heard of the others.  I guess as a MH-E developer I
should try the competition to see what MH-E lacks...  But it doesn't
lack MIME!  :-)

Peter

Re: RMAIL, MIME-related bug

[Eli Zaretskii]

> Date: Fri, 17 Oct 2003 11:39:24 -0400
> From: Peter S Galbraith <p.galbraith@globetrotter.net>
> 
> >            If they did it the Right Way, we would not need to have
> > this discussion now, just point Alexander to the existing functions.
> 
> The only MIME functions currently in Emacs are from gnus, so point him
> at those.

They should be in lisp/mail/, not in lisp/gnus/.  In other words, they
should be in common Emacs infrastructure, documented in
lispref/*.texi, and all the Emacs mail packages should use them.

Re: RMAIL, MIME-related bug

[Peter S Galbraith]

Eli Zaretskii <eliz@elta.co.il> wrote:

> > Date: Fri, 17 Oct 2003 11:39:24 -0400
> > From: Peter S Galbraith <p.galbraith@globetrotter.net>
> > 
> > >            If they did it the Right Way, we would not need to have
> > > this discussion now, just point Alexander to the existing functions.
> > 
> > The only MIME functions currently in Emacs are from gnus, so point him
> > at those.
> 
> They should be in lisp/mail/, not in lisp/gnus/.  In other words, they
> should be in common Emacs infrastructure, documented in
> lispref/*.texi, and all the Emacs mail packages should use them.

That sounds like a pretty good idea to me.

The drawback for us is the very slow release cycle of Emacs (e.g. the
released version of MH-E with Emacs is two years old).  Currently, some
fancier capabilities of MH-E are only availble if the user has also
installed a separate recent version of gnus since the Emacs version is
too old.  I suppose we would solve that problem by packaging a current
snapshot of the Emacs MIME package (if it existed), but we would have to
maintain a fork if you used code that is not backward compatible with
older versions of Emacs.

-- 
Peter S. Galbraith, MH-E developer  <p.galbraith@globetrotter.net>
GPG key 1024/D2A913A1 - 97CE 866F F579 96EE  6E68 8170 35FF 799E
6623'rd GNU/Linux user at the Counter - http://counter.li.org/

Re: RMAIL, MIME-related bug

[Richard Stallman]

    > They should be in lisp/mail/, not in lisp/gnus/.  In other words, they
    > should be in common Emacs infrastructure, documented in
    > lispref/*.texi, and all the Emacs mail packages should use them.

If they are a general facility, they should definitely be moved;
the main repository for them should be the Emacs repository.

      Currently, some
    fancier capabilities of MH-E are only availble if the user has also
    installed a separate recent version of gnus since the Emacs version is
    too old.

If you distribute MH-E outside of Emacs, you can distribute whatever
you like with it.

Re: RMAIL, MIME-related bug

[Richard Stallman]

I have already decided to switch to the new version of Rmail
that uses mbox format instead of Babyl format.  It is waiting
for more testing and debugging.  New MIME support needs to be
designed to work with mbox format.

Preserving mime messages in their original transferred format is the
only acceptable way to handle them.  Machines now so fast that it
should not take any substantial time to decode base64 or quoted
printables, so we will do that when displaying a message.

So my decision is that Rmail will continue to store MIME
contents in its undecoded form.  Please do not keep arguing
for other methods, because my mind is made up.

Re: RMAIL, MIME-related bug

[Stefan Monnier]

> that uses mbox format instead of Babyl format.  It is waiting
> for more testing and debugging.

Maybe installing on the CVS trunk would result in more testing (and
debugging) ?

BTW, when's the feature freeze ?


        Stefan

Re: RMAIL, MIME-related bug

[Richard Stallman]

    > that uses mbox format instead of Babyl format.  It is waiting
    > for more testing and debugging.

    Maybe installing on the CVS trunk would result in more testing (and
    debugging) ?

It certainly would, but I think it needs a bit more testing first.
Could someone please try it out?

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     > that uses mbox format instead of Babyl format.  It is waiting
>     > for more testing and debugging.
> 
>     Maybe installing on the CVS trunk would result in more testing (and
>     debugging) ?
> 
> It certainly would, but I think it needs a bit more testing first.
> Could someone please try it out?

Yes, I'm going to do that.

-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, rmail-mbox-branch

[Alexander Pohoyda]

Problems I have encountered so far:

1) If RMAIL file does not exist, rmail-display-labels function fails
deep inside rmaildesc.el and I dont see a reason to display labels if
there are no messages.

Proposed solution:
Index: rmail.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mail/rmail.el,v
retrieving revision 1.368.2.5
diff -u -r1.368.2.5 rmail.el
--- rmail.el    23 Feb 2003 00:33:25 -0000      1.368.2.5
+++ rmail.el    22 Oct 2003 19:42:05 -0000
@@ -2458,7 +2460,6 @@
       ;; out of the Rmail file so as not to break other mail agents.
       (progn
         (message "No messages to show.  Add something better soon.")
-        (rmail-display-labels)
         (force-mode-line-update))
 
     ;; There are messages.  Show one.


2) rmail-use-spam-filter is void variable, used in rmail-get-new-mail
   function. It is defined in rmail-spam-filter.el, but we cannot
   (require 'rmail-spam-filter) before the rmail-mode-map variable is
   defined further in rmail.el file.

   I'm not sure what is a right way to fix this.


3) Deleting the last message makes rmail-summary-goto-msg to call
   itself recursively in a dead loop.

Proposed solution:
Index: rmailsum.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mail/rmailsum.el,v
retrieving revision 1.127.2.2
diff -u -r1.127.2.2 rmailsum.el
--- rmailsum.el 18 Feb 2003 16:47:23 -0000      1.127.2.2
+++ rmailsum.el 22 Oct 2003 20:22:17 -0000
@@ -1081,7 +1081,8 @@
       (if (< n 1)
          (progn (message "No preceding message")
                 (setq n 1)))
-      (if (> n total)
+      (if (and (> n total)
+              (> total 0))
          (progn (message "No following message")
                 (goto-char (point-max))
                 (rmail-summary-goto-msg nil nowarn skip-rmail)))


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, rmail-mbox-branch

[Richard Stallman]

    1) If RMAIL file does not exist, rmail-display-labels function fails
    deep inside rmaildesc.el and I dont see a reason to display labels if
    there are no messages.

If nothing is done, will the labels from the previously displayed
message hang around in the modeline?  If so, we should fix
rmail-display-labels so it does the right thing when there is no
message.  If not, your fix seems right.  Which one is it?

    2) rmail-use-spam-filter is void variable, used in rmail-get-new-mail
       function. It is defined in rmail-spam-filter.el, but we cannot
       (require 'rmail-spam-filter) before the rmail-mode-map variable is
       defined further in rmail.el file.

       I'm not sure what is a right way to fix this.

How about initializing the variable to nil, and making
rmail-get-new-mail ignore it when it's nil?



How about doing the require at a place such as the function `rmail' so that we know rmail-mode-map is already set up?

Re: RMAIL, rmail-mbox-branch

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     1) If RMAIL file does not exist, rmail-display-labels function
>        fails deep inside rmaildesc.el and I dont see a reason to
>        display labels if there are no messages. 
> 
> If nothing is done, will the labels from the previously displayed
> message hang around in the modeline?  If so, we should fix
> rmail-display-labels so it does the right thing when there is no
> message.  If not, your fix seems right.  Which one is it?

You were right: we need to clean the modeline after deleting the last
message. Fixed.


>     2) rmail-use-spam-filter is void variable, used in
>        rmail-get-new-mail function. It is defined in
>        rmail-spam-filter.el, but we cannot (require
>        'rmail-spam-filter) before the rmail-mode-map variable is
>        defined further in rmail.el file.
> 
> How about doing the require at a place such as the function `rmail'
> so that we know rmail-mode-map is already set up?

This approach worked. Fixed.


Other notes:
1) mail-utils is required for mail-strip-quoted-names function;
2) I changed the label separator in the modeline from " " (just
   space) to ", " (comma followed by space), which looks better, I
   believe;
3) if a message has no labels (the result variable is an empty
   string), there is no need to append a space in the end:
       orig (RMAIL 1/1 ) vs. new (RMAIL 1/1)
4) if there are labels, separate them with a semicolon:
       orig (RMAIL 1/1 deleted label2) vs. new
       new (RMAIL 1/1; deleted, label2)
5) if the last message is deleted or the RMAIL file is empty,
   display (RMAIL no messages) in the modeline;
6) the change in rmailsum.el should have been applied already, but
   is, obviously, not.


Please consider the following patch.

Index: rmail.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mail/rmail.el,v
retrieving revision 1.368.2.5
diff -u -r1.368.2.5 rmail.el
--- rmail.el	23 Feb 2003 00:33:25 -0000	1.368.2.5
+++ rmail.el	26 Nov 2003 22:21:37 -0000
@@ -49,6 +49,7 @@
 
 (eval-and-compile
   (require 'browse-url)
+  (require 'mail-utils)
   (require 'rmaildesc)
   (require 'rmailhdr))
 
@@ -645,6 +646,7 @@
 If `rmail-display-summary' is non-nil, make a summary for this RMAIL file."
   (interactive (if current-prefix-arg
 		   (list (read-file-name "Run rmail on RMAIL file: "))))
+  (require 'rmail-spam-filter)
   (rmail-require-mime-maybe)
   (let* ((file-name (expand-file-name (or file-name-arg rmail-file-name)))
 	 ;; Use find-buffer-visiting, not get-file-buffer, for those users
@@ -2126,13 +2128,14 @@
         (setq keyword-list (rmail-desc-get-keywords rmail-current-message)))
 
     ;; Generate the result string.
-    (setq result (mapconcat '(lambda (arg) arg) keyword-list " "))
+    (setq result (mapconcat '(lambda (arg) arg) keyword-list ", "))
 
     ;; Update the mode line to display the keywords, the current
     ;; message index and the total number of messages.
     (setq mode-line-process
-	  (format " %d/%d %s"
-		  rmail-current-message rmail-total-messages result))
+	  (concat (format " %d/%d" rmail-current-message rmail-total-messages)
+		  (unless (string-equal result "")
+		    (concat "; " result))))
 
     ;; If rmail-enable-mime is non-nil, we may have to update
     ;; `mode-line-process' of rmail-view-buffer too.
@@ -2458,7 +2461,7 @@
       ;; out of the Rmail file so as not to break other mail agents.
       (progn
         (message "No messages to show.  Add something better soon.")
-        (rmail-display-labels)
+        (setq mode-line-process " no messages")
         (force-mode-line-update))
 
     ;; There are messages.  Show one.
Index: rmailsum.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mail/rmailsum.el,v
retrieving revision 1.127.2.2
diff -u -r1.127.2.2 rmailsum.el
--- rmailsum.el	18 Feb 2003 16:47:23 -0000	1.127.2.2
+++ rmailsum.el	26 Nov 2003 22:21:38 -0000
@@ -1081,7 +1081,8 @@
       (if (< n 1)
 	  (progn (message "No preceding message")
 		 (setq n 1)))
-      (if (> n total)
+      (if (and (> n total)
+	       (> total 0))
 	  (progn (message "No following message")
 		 (goto-char (point-max))
 		 (rmail-summary-goto-msg nil nowarn skip-rmail)))


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > When we convert the email to babyl format, we can do some
> > MIME-related processing on it, for example: all text/* bodyparts
> > may be transfer-encoding (quoted-printable and base64) decoded,
> > PGP/GPG signatures verified, PGP/GPG decryption done, header
> > fields of type =?...?B?...?= decoded (RFC 2047) and unfolded (RFC
> > 2822), etc. This needs to be done once. No information is lost in
> > this step. No structure information is lost either.
> 
> In order not to lose information, you need to keep the GPG
> signatures you have just verified since you can't re-create them
> yourself.

Sure, I'm just hiding that bodypart at display time.

>                                                             Of
> course, you also need to keep the signed-text unless you're
> super-extra-careful to make sure that you can re-create the exact
> same byte-sequence from the rest of the data, which is rather
> unlikely.

OK, let's keep the signed text un-changed, but I would prefer to do
the decoding on normal messages. As Eli points out, this is logical
to do once on message arrival.


> Why do people even consider doing any processing at that point?

Just to optimise the process. Doing it every time in show-message is
even simplier from the programmer's point of view.


> The processing should be done for display and nothing else, because
> any other option will make you lose information at some point and
> also forces you to have code to re-create the original format,
> whereas the "display-side processing" approach only needs to parse
> MIME but never needs to re-construct it.

You are right, but let's focus on the need not to invent the
RMAIL-MIME, no additional header in between the message. Do you agree
that hiding header fields is preferred to having two message headers?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Stefan Monnier]

>> Of course, you also need to keep the signed-text unless you're
>> super-extra-careful to make sure that you can re-create the exact same
>> byte-sequence from the rest of the data, which is rather unlikely.

> OK, let's keep the signed text un-changed, but I would prefer to do
> the decoding on normal messages. As Eli points out, this is logical
> to do once on message arrival.

I see nothing logical about it.  AFAICT, the message will be saved somehow
in a text file, so you'll need to use some kind of unambiguous textual
representation of the various parts of the message.  Of course, you can
re-invent the wheel or use another existing wheel (the builtin lisp
printer), but using the original MIME representation is a pretty
natural choice.

>> Why do people even consider doing any processing at that point?
> Just to optimise the process. Doing it every time in show-message is
> even simplier from the programmer's point of view.

I'd first concentrate on getting something working correctly.
Especially since there is no evidence that performance will be a problem,
let alone that a pre-processed form will be more efficient.

> You are right, but let's focus on the need not to invent the
> RMAIL-MIME, no additional header in between the message. Do you agree
> that hiding header fields is preferred to having two message headers?

I don't really know the details of what this is referring to.
I generally like approaches based on adding text-properties and overlays
rather than modifying buffer text, but modifying buffer text can be much
simpler, with fewer surprises and much more flexible (I like my headers to
be sorted for example, which can't be done just by hiding undesirable
header fields).


        Stefan

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > When we convert the email to babyl format, we can do some
> > MIME-related processing on it, for example: all text/* bodyparts
> > may be transfer-encoding (quoted-printable and base64) decoded,
> > PGP/GPG signatures verified, PGP/GPG decryption done, header
> > fields of type =?...?B?...?= decoded (RFC 2047) and unfolded (RFC
> > 2822), etc. This needs to be done once. No information is lost in
> > this step. No structure information is lost either.
> 
> In order not to lose information, you need to keep the GPG
> signatures you have just verified since you can't re-create them
> yourself.

Sure, I'm just hiding that bodypart at display time.

>                                                             Of
> course, you also need to keep the signed-text unless you're
> super-extra-careful to make sure that you can re-create the exact
> same byte-sequence from the rest of the data, which is rather
> unlikely.

OK, let's keep the signed text un-changed, but I would prefer to do
the decoding on normal messages. As Eli points out, this is logical
to do once on message arrival.


> Why do people even consider doing any processing at that point?

Just to optimise the process. Doing it every time in show-message is
even simplier from the programmer's point of view.


> The processing should be done for display and nothing else, because
> any other option will make you lose information at some point and
> also forces you to have code to re-create the original format,
> whereas the "display-side processing" approach only needs to parse
> MIME but never needs to re-construct it.

You are right, but let's focus on the need not to invent the
RMAIL-MIME, no additional header in between the message. Do you agree
that hiding header fields is preferred to having two message headers?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Juri Linkov]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> Why do people even consider doing any processing at that point?
> The processing should be done for display and nothing else, because any
> other option will make you lose information at some point and also forces
> you to have code to re-create the original format, whereas the "display-side
> processing" approach only needs to parse MIME but never needs to
> re-construct it.

I will not argue about the default mbox format (it's pretty obvious that
messages should be preserved in their original transferred format).
But I'll tell about functionality still missing in Emacs.

1. Often there is a need to grep the mail archive for some old message.
This is impossible if message is encoded in base64/quoted-printable.

2. Sometimes there is a need to make a bookmark to the message to be
able to quickly return to it later.  Hopeless.  Only one way to fetch
old message is to start MUA and browse through dozens of folders and
hundreds of messages in every folder.

I see one solution to these problems - to export entire mbox to the
file system, i.e. to save MIME parts to separate files, decode
base64/quoted-printable regions, convert the charset from Content-Type
line to Emacs encoding, add corresponding -*- coding: -*- line, and
save fully decoded message to a separate file.

Note that this don't contradict the decision to store messages in mbox
in their undecoded form.  The proposed solution duplicates the content
of messages in the decoded form.  Hard disks now so cheap that having
two copies of the same message is not a problem.  The decoded messages
could also be used as a cache to make displaying messages faster,
whereas undecoded messages will be available to resend forwards, where
no original information should be lost.  There should be some way to
correlate between them, i.e. to find corresponding decoded message
from undecoded one, and vice versa.

-- 
http://www.jurta.org/emacs/

Re: RMAIL, MIME-related bug

[Kenichi Handa]

Juri Linkov <juri@jurta.org> writes:
> I see one solution to these problems - to export entire mbox to the
> file system, i.e. to save MIME parts to separate files, decode
> base64/quoted-printable regions, convert the charset from Content-Type
> line to Emacs encoding, add corresponding -*- coding: -*- line, and
> save fully decoded message to a separate file.

> Note that this don't contradict the decision to store messages in mbox
> in their undecoded form.  The proposed solution duplicates the content
> of messages in the decoded form.  Hard disks now so cheap that having
> two copies of the same message is not a problem.  The decoded messages
> could also be used as a cache to make displaying messages faster,
> whereas undecoded messages will be available to resend forwards, where
> no original information should be lost.  There should be some way to
> correlate between them, i.e. to find corresponding decoded message
> from undecoded one, and vice versa.

This method is very similar to what I proposed in my
previous mail.

Kenichi Handa <handa@m17n.org> writes:
> (1) Read RMAIL file without decoding into some hidden source
>     buffer (unibyte).  It may be ok to process only
>     Content-Transfer-Encoding.
> (2) Prepare a view buffer.
> (3) Insert the current message in the view buffer after decoding it.
> (4) A background process (run by idle timer?) decodes not
>     yet decoded message into the view buffer (like
>     jit-lock-stealth-fontify).

Mine doesn't save the view buffer in a file, yours does.

---
Ken'ichi HANDA
handa@m17n.org

Re: RMAIL, MIME-related bug

[Juri Linkov]

Kenichi Handa <handa@m17n.org> writes:
> Juri Linkov <juri@jurta.org> writes:
> > I see one solution to these problems - to export entire mbox to the
> > file system, i.e. to save MIME parts to separate files, decode
> > base64/quoted-printable regions, convert the charset from Content-Type
> > line to Emacs encoding, add corresponding -*- coding: -*- line, and
> > save fully decoded message to a separate file.
> 
> > Note that this don't contradict the decision to store messages in mbox
> > in their undecoded form.  The proposed solution duplicates the content
> > of messages in the decoded form.  Hard disks now so cheap that having
> > two copies of the same message is not a problem.  The decoded messages
> > could also be used as a cache to make displaying messages faster,
> > whereas undecoded messages will be available to resend forwards, where
> > no original information should be lost.  There should be some way to
> > correlate between them, i.e. to find corresponding decoded message
> > from undecoded one, and vice versa.
> 
> This method is very similar to what I proposed in my
> previous mail.
> 
> Kenichi Handa <handa@m17n.org> writes:
> > (1) Read RMAIL file without decoding into some hidden source
> >     buffer (unibyte).  It may be ok to process only
> >     Content-Transfer-Encoding.
> > (2) Prepare a view buffer.
> > (3) Insert the current message in the view buffer after decoding it.
> > (4) A background process (run by idle timer?) decodes not
> >     yet decoded message into the view buffer (like
> >     jit-lock-stealth-fontify).
> 
> Mine doesn't save the view buffer in a file, yours does.

Yes, this method is very similar to yours.  However, I added saving of
decoded messages in files to solve the mentioned problems:

1. Mail archives with fully decoded messages can be grepped, if they are
   stored in files;

2. It's possible to refer to separate messages as to ordinary files.

-- 
http://www.jurta.org/emacs/

Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Kenichi Handa <handa@m17n.org> writes:

> > I see one solution to these problems - to export entire mbox to
> > the file system, i.e. to save MIME parts to separate files, decode
> > base64/quoted-printable regions, convert the charset from
> > Content-Type line to Emacs encoding, add corresponding -*- coding:
> > -*- line, and save fully decoded message to a separate file.
> 
> > Note that this don't contradict the decision to store messages in
> > mbox in their undecoded form.  The proposed solution duplicates
> > the content of messages in the decoded form.  Hard disks now so
> > cheap that having two copies of the same message is not a problem.
> > The decoded messages could also be used as a cache to make
> > displaying messages faster, whereas undecoded messages will be
> > available to resend forwards, where no original information should
> > be lost.  There should be some way to correlate between them,
> > i.e. to find corresponding decoded message from undecoded one, and
> > vice versa.
 
> This method is very similar to what I proposed in my
> previous mail.
> 
> Kenichi Handa <handa@m17n.org> writes:
> > (1) Read RMAIL file without decoding into some hidden source
> >     buffer (unibyte).  It may be ok to process only
> >     Content-Transfer-Encoding.
> > (2) Prepare a view buffer.
> > (3) Insert the current message in the view buffer after decoding
> >     it. 
> > (4) A background process (run by idle timer?) decodes not
> >     yet decoded message into the view buffer (like
> >     jit-lock-stealth-fontify).
> 
> Mine doesn't save the view buffer in a file, yours does.

I like these ideas very much and I'll keep them in my mind.
Thank you very much!


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME-related bug

[Robert J. Chassell]

   Juri Linkov <juri@jurta.org> writes:
   > I see one solution to these problems - to export entire mbox to the
   > file system, i.e. to save MIME parts to separate files, ....

   > Note that this don't contradict the decision to store messages in mbox
   > in their undecoded form.  ....

It is useful to use the terms `deep representation' and `surface
expressions' to distinguish between the various formats.

Think of the mbox as the `deep representation' of the set of messages.
Much of it is readable using `find-file-literally' as it should be.
But various `surface expressions' make reading the file easier, and
decode images or base64 encoded material as needed.  `Surface
expressions' can be cached -- that can be an option.

And, of course,  a particular  `surface expression', such as a Babyl
file format, can be a  `deep representation' for further processing,
such as one to show an image.

In any event, a `surface expression' may be suited to audio, using
Emacspeak, or suited to rmail, or gnus, or...

This method is similar to Kenichi Handa's proposal, excepting that he
speaks of a `view buffer', which is a good phrase but does not
persuade programmers to think of the blind.  

(Emacspeak may well use a `view buffer' -- and not deal with images in
it.  The idea is to apply to mbox format the existing way in which
people think about Texinfo, in which the `deep representation', the
Texinfo source, has many `surface expressions', such as Info, DVI,
HTML, PostScript, and plain text.)

The `deep representation/surface expressions' way of thinking goes
against traditional Emacs style:  in that style, the `surface
expression' of a buffer was very closely linked to its `deep
representation'.  The characters you saw on the screen represented the
bytes in the file.

It is vital to keep this ability.  Just yesterday, I had to look at a
mail file using `find-file-literally' to discover what was giving me
trouble.  But mostly, I do not use `find-file-literally' but look at
the `surface expression' produced by rmail.  Obviously, this `surface
expression' is not hugely different from the mail file's `deep
representation', but it is somewhat different.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: RMAIL, MIME-related bug

[Lars Magne Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

> I see one solution to these problems - to export entire mbox to the
> file system, i.e. to save MIME parts to separate files, decode
> base64/quoted-printable regions, convert the charset from Content-Type
> line to Emacs encoding, add corresponding -*- coding: -*- line, and
> save fully decoded message to a separate file.

And all that just to be able to use grep?  Why not have the mail
reader be able to do searches for you instead?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: RMAIL, MIME-related bug

[Juri Linkov]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Juri Linkov <juri@jurta.org> writes:
> > I see one solution to these problems - to export entire mbox to the
> > file system, i.e. to save MIME parts to separate files, decode
> > base64/quoted-printable regions, convert the charset from Content-Type
> > line to Emacs encoding, add corresponding -*- coding: -*- line, and
> > save fully decoded message to a separate file.
> 
> And all that just to be able to use grep?  Why not have the mail
> reader be able to do searches for you instead?

Searches done by mail reader are not effective (or I'd rather say they are
"effective" with the first letter "d", i.e. "defective" :-), because
mail reader needs to parse MIME parts and decode base64/qp regions on
every of hundreds messages, and repeat all this again on every new search.

-- 
http://www.jurta.org/emacs/

Re: RMAIL, MIME-related bug

[Lars Magne Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

>> And all that just to be able to use grep?  Why not have the mail
>> reader be able to do searches for you instead?
>
> Searches done by mail reader are not effective (or I'd rather say they are
> "effective" with the first letter "d", i.e. "defective" :-), because
> mail reader needs to parse MIME parts and decode base64/qp regions on
> every of hundreds messages, and repeat all this again on every new search.

Perhaps, perhaps not.  Some mailers (I've been told) generate indexes
when they receive messages.  When you do searches, the mailer looks
stuff up in the index.

Grepping several GBs worth of mail isn't very efficient.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: RMAIL, MIME-related bug

[Paul Michael Reilly]

Lars Magne Ingebrigtsen wrote:

>Juri Linkov <juri@jurta.org> writes:
>
>  
>
>>I see one solution to these problems - to export entire mbox to the
>>file system, i.e. to save MIME parts to separate files, decode
>>base64/quoted-printable regions, convert the charset from Content-Type
>>line to Emacs encoding, add corresponding -*- coding: -*- line, and
>>save fully decoded message to a separate file.
>>    
>>
>
>And all that just to be able to use grep?  Why not have the mail
>reader be able to do searches for you instead?
>
That's the right answer.  Using grep is fine to the extent that one 
cannot really expect grep to grok the internals of a mail application.  
IMAP provides a decent model for mail searching.  Gnus might as well.  
I'm just not as familiar with Gnus as I am with IMAP.

-pmr

Re: RMAIL, MIME-related bug

[Satyaki Das]

Juri Linkov <juri@jurta.org> writes:

> 1. Often there is a need to grep the mail archive for some old message.
> This is impossible if message is encoded in base64/quoted-printable.

I am a huge fan of mail indexing programs like: swish++, mairix,
glimpse, namazu etc. Many of these will decode base64 and
quoted-printable parts. Also they are much faster than grep can
ever hope to be.

Many Emacs based email clients (like Gnus, MH-E) have interfaces
to these programs. May be rmail can be improved to support these
programs?

Satyaki

Re: RMAIL, MIME-related bug

[Richard Stallman]

    I am a huge fan of mail indexing programs like: swish++, mairix,
    glimpse, namazu etc.

I seem to recall that glimpse is or was non-free.  I don't know about
the others.  Can you check which of these are non-free?  We don't
want Gnus or MH-E to refer to them.

Re: RMAIL, MIME-related bug

[Satyaki Das]

Richard Stallman <rms@gnu.org> writes:

>     I am a huge fan of mail indexing programs like: swish++, mairix,
>     glimpse, namazu etc.
> 
> I seem to recall that glimpse is or was non-free.  I don't know about
> the others.  Can you check which of these are non-free?  We don't
> want Gnus or MH-E to refer to them.

MH-E supports the use of swish++, swish-e, mairix, namazu and
glimpse. Except for glimpse the rest are all free and distributed
under the GPL.

We only have a customizable option that allows the user to choose
to use glimpse.

Satyaki

Re: RMAIL, MIME-related bug

[Richard Stallman]

    1. Often there is a need to grep the mail archive for some old message.
    This is impossible if message is encoded in base64/quoted-printable.

It just means it might be useful for the program that searches to know
how to decode attachments.

    2. Sometimes there is a need to make a bookmark to the message to be
    able to quickly return to it later.

That could mean various things--I don't understand why you think it is
so hard.

       Only one way to fetch
    old message is to start MUA and browse through dozens of folders and
    hundreds of messages in every folder.

That is certainly not the only way.  The way I normally do this is
with grep.  It works pretty well, but it could be better.

I think we could use a program designed to search through mail folders
in mbox format.  Such a program could be convenient in many ways.  For
instance, it could have a feature to decode base64 and
quoted-printable encodings.  It could also have the ability to search
for matches against specific header fields, or against the body, and
handle boolean combinations of such criteria.

It should output the messages that meet the specified criterion, and
add to each message something in the form of a header field that says
which file it came from and which line number.  That way another
program could look at the output and find the relevant messages in the
files where they originally came from.

If the output gives you too many messages, you could apply the search
program to the output of the previous run, to filter it further.

It would not be a very big job to write this program by adapting grep.
Would anyone like to try?

Re: RMAIL, MIME-related bug

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> It should output the messages that meet the specified criterion, and
> add to each message something in the form of a header field that says
> which file it came from and which line number.

As a Gnus user I'd like to see results end up in a virtual Group
(folder).

> If the output gives you too many messages, you could apply the search
> program to the output of the previous run, to filter it further.

Gnus already offers useful search capabilities :)

> It would not be a very big job to write this program by adapting grep.

To match against header fields and similar elements you can use
http://www.cs.helsinki.fi/~jjaakkol/sgrep.html

-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)

Re: RMAIL, MIME-related bug

[Richard Stallman]

    > It should output the messages that meet the specified criterion, and
    > add to each message something in the form of a header field that says
    > which file it came from and which line number.

    As a Gnus user I'd like to see results end up in a virtual Group
    (folder).

The program I envision is a shell command.  How Gnus might invoke it
is a separate issue.  Since I don't know Gnus, I won't say anything
about that.

Re: RMAIL, MIME-related bug

[Kevin Rodgers]

Juri Linkov wrote:

> 2. Sometimes there is a need to make a bookmark to the message to be
> able to quickly return to it later.  Hopeless.  Only one way to fetch
> old message is to start MUA and browse through dozens of folders and
> hundreds of messages in every folder.

I did a little work on this issue about 2 1/2 years ago.  My approach
was to define a bookmark as a URL whose protocol is "mailmessage", so
that I could use Emacs' url.el library to parse it and ange-ftp.el to
access remote //[USER@]HOST folders.  However, I wrote it as an add-on
to VM, so the code that actually views the folder and selects the
message would have to be converted to Rmail.  And it would have to be
extended to handle IMAP folders (cf. file folders).

-- 
Kevin Rodgers

Re: RMAIL, MIME-related bug

[Juri Linkov]

Kevin Rodgers <ihs_4664@yahoo.com> writes:
> Juri Linkov wrote:
> > 2. Sometimes there is a need to make a bookmark to the message to be
> > able to quickly return to it later.  Hopeless.  Only one way to fetch
> > old message is to start MUA and browse through dozens of folders and
> > hundreds of messages in every folder.
> 
> I did a little work on this issue about 2 1/2 years ago.  My approach
> was to define a bookmark as a URL whose protocol is "mailmessage", so
> that I could use Emacs' url.el library to parse it and ange-ftp.el to
> access remote //[USER@]HOST folders.  However, I wrote it as an add-on
> to VM, so the code that actually views the folder and selects the
> message would have to be converted to Rmail.  And it would have to be
> extended to handle IMAP folders (cf. file folders).

Using URL for references to messages is a good solution, but instead
of inventing ad hoc protocol name, it's better to use standard name
"mid" defined by http://www.ietf.org/rfc/rfc2392.txt.

Then, for example, opening the link <mid:3F9471FB.4000609@yahoo.com>
should start a mail reader, find corresponding message by its
Message-ID, prepare article buffer and switch to it (e.g. in case of
Gnus to call the function `gnus-summary-goto-article'; other mail
readers should have a similar function).

I'm not sure yet, where this could be implemented: url.el is not part
of Emacs (BTW: Why?); thingatpt.el mentions this protocol name, but
that's all; perhaps this should be done partially in ffap.el.

-- 
http://www.jurta.org/emacs/

URL (was: RMAIL, MIME-related bug)

[Stefan Monnier]

> I'm not sure yet, where this could be implemented: url.el is not part
> of Emacs (BTW: Why?); [...]

Good question.  I've been bugging Bill and Dave every once in a while to
move URL into Emacs, but it somehow still hasn't happened, after
many months.

Could we get this todo-item moving ?


        Stefan

Re: URL

[Dave Love]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Good question.  I've been bugging Bill and Dave every once in a while to
> move URL into Emacs, but it somehow still hasn't happened, after
> many months.

I'm not sure it's anything to do with me.

If I remember correctly, you wanted to link the repository on
subversions into the Emacs one.  There's nothing I can do about that,
even if I thought it was a good idea.

[What does this have to do with Rmail and MIME?  For what it's worth,
you should actually _not_ make network connexions when reading mail,
and Gnus will prevent that happening via the unreleased url.  Arguably
that should be done by a hook directly into the Emacs networking code,
but I suspect there's not enough use of W3 to warrant suppressing mail
bugging in that way.]

Re: URL

[Stefan Monnier]

>> Good question.  I've been bugging Bill and Dave every once in a while to
>> move URL into Emacs, but it somehow still hasn't happened, after
>> many months.

> I'm not sure it's anything to do with me.

> If I remember correctly, you wanted to link the repository on
> subversions into the Emacs one.  There's nothing I can do about that,
> even if I thought it was a good idea.

I want it linked, or moved (preferably moved).  In either case, you can't do
it yourself, but as an admin of URL (IIRC) you could ask the cvshackers to
do the move/link, whereas I can't.  At least that's my understanding.
But maybe it's flawed because you're not an admin of Emacs, so RMS or Eli
should ask for it together with you, maybe ?

In any case, not being an admin of either makes me even more powerless
w.r.t this.

> [What does this have to do with Rmail and MIME?

It was about generating URLs of the form `mid://...' for bookmarking
Rmail messages.

> For what it's worth,
> you should actually _not_ make network connexions when reading mail,
> and Gnus will prevent that happening via the unreleased url.

100% agreement.


        Stefan

Re: URL

[Richard Stallman]

    >> Good question.  I've been bugging Bill and Dave every once in a while to
    >> move URL into Emacs, but it somehow still hasn't happened, after
    >> many months.

what again is "URL"?  who wrote it & what does it do?

    I want it linked, or moved (preferably moved).

i dont know what this refers to.  what moved where?

Re: URL

[Dave Love]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> I want it linked, or moved (preferably moved).  In either case, you can't do
> it yourself, but as an admin of URL (IIRC)

As far as I know, I just have much-neglected write access to its CVS.

> It was about generating URLs of the form `mid://...' for bookmarking
> Rmail messages.

I don't think URL has support for that, and I think it would require
support from user agents.  They would need to define a stable function
to be called to look up the message (assuming you can rely on
`read-mail-command' to be what the user wants to use).  Doesn't it
make more sense to put it in browse-url for a mail agent's use?

Re: URL

[Juri Linkov]

Dave Love <d.love@dl.ac.uk> writes:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
> > I want it linked, or moved (preferably moved).  In either case, you can't do
> > it yourself, but as an admin of URL (IIRC)
> 
> As far as I know, I just have much-neglected write access to its CVS.
> 
> > It was about generating URLs of the form `mid://...' for bookmarking
> > Rmail messages.
> 
> I don't think URL has support for that, and I think it would require
> support from user agents.  They would need to define a stable function
> to be called to look up the message (assuming you can rely on
> `read-mail-command' to be what the user wants to use).  Doesn't it
> make more sense to put it in browse-url for a mail agent's use?

It makes sense to put in browse-url a call to the new function
`goto-mail' proposed in <mid:87vfqbdw8e.fsf_-_@mail.jurta.org>
(sorry, this link don't work yet ;-)

-- 
http://www.jurta.org/emacs/

Re: RMAIL, MIME-related bug

[Kevin Rodgers]

Juri Linkov wrote:

> Kevin Rodgers <ihs_4664@yahoo.com> writes:
>>I did a little work on this issue about 2 1/2 years ago.  My approach
>>was to define a bookmark as a URL whose protocol is "mailmessage", so
>>that I could use Emacs' url.el library to parse it and ange-ftp.el to
>>access remote //[USER@]HOST folders.  However, I wrote it as an add-on
>>to VM, so the code that actually views the folder and selects the
>>message would have to be converted to Rmail.  And it would have to be
>>extended to handle IMAP folders (cf. file folders).
> 
> Using URL for references to messages is a good solution, but instead
> of inventing ad hoc protocol name, it's better to use standard name
> "mid" defined by http://www.ietf.org/rfc/rfc2392.txt.


Thanks for the pointer, but I find that document somewhat disappointing.

For one thing, I was confused by this:

	A "cid" URL is converted to the corresponding Content-ID message
	header [MIME] by removing the "cid:" prefix, converting the % encoded
	character to their equivalent US-ASCII characters, and enclosing the
	remaining parts with an angle bracket pair, "<" and ">".  For example,
	"cid:foo4%25foo1@bar.net" corresponds to

	    Content-ID: <foo4%25foo1@bar.net>

	Reversing the process and converting URL special characters to their
	% encodings produces the original cid.

	A "mid" URL is converted to a Message-ID or Message-ID/Content-ID
	pair in a similar fashion.

Shouldn't "%25" have been converted to "%":

	Content-ID: <foo4%foo1@bar.net>

But more importantly, the mid and cid URLs do not actually specify a
LOCATION: that makes them more like a URN than a URL.


> Then, for example, opening the link <mid:3F9471FB.4000609@yahoo.com>
> should start a mail reader, find corresponding message by its
> Message-ID, prepare article buffer and switch to it (e.g. in case of
> Gnus to call the function `gnus-summary-goto-article'; other mail
> readers should have a similar function).


Shouldn't the cid and mid schemes specify a location via the Common
Internet Scheme Syntax defined in RFC 1738?  That way, you could specify
a folder file, or a POP or IMAP server (and user and password).


> I'm not sure yet, where this could be implemented: url.el is not part
> of Emacs (BTW: Why?); thingatpt.el mentions this protocol name, but
> that's all; perhaps this should be done partially in ffap.el.

As long as it respects the read-mail-command variable.  To do that
correctly, I think we would need to define an interface like compose-mail
that would accept all the arguments that might be necessary to specify a
message (folder file and format; or server, protocol, user, and password;
plus message id); then a new utility define-read-mail-command (analogous to
define-mail-user-agent) that would associate each read-mail-command to a
function that supports that interface.


Otherwise, how would Emacs know where to search for the Message-Id?

-- 
Kevin Rodgers

Re: RMAIL, MIME-related bug

[Kevin Rodgers]

Kevin Rodgers wrote:

> Juri Linkov wrote:
>> Using URL for references to messages is a good solution, but instead
>> of inventing ad hoc protocol name, it's better to use standard name
>> "mid" defined by http://www.ietf.org/rfc/rfc2392.txt.
> 
> Thanks for the pointer, but I find that document somewhat disappointing.
...
> But more importantly, the mid and cid URLs do not actually specify a
> LOCATION: that makes them more like a URN than a URL.


And it makes them similar to the news:<message-id> URL scheme.  But
there is also a nntp://<host>:<port>/<newsgroup>/<article> URL scheme,
which I think is closer to what we need.


> Shouldn't the cid and mid schemes specify a location via the Common
> Internet Scheme Syntax defined in RFC 1738?  That way, you could specify
> a folder file, or a POP or IMAP server (and user and password).

We could define separate URL schemes for mbox, POP, and IMAP access, but
I think for now I'm going to pursue my origial idea, but rename it to
conform to the standard for experimental schemes:

x-mid:[//[user@]host]/path/to/folder#message-id

-- 
Kevin Rodgers

Re: URL

[Juri Linkov]

Kevin Rodgers <ihs_4664@yahoo.com> writes:
> Juri Linkov wrote:
> > Using URL for references to messages is a good solution, but
> > instead of inventing ad hoc protocol name, it's better to use
> > standard name "mid" defined by
> > http://www.ietf.org/rfc/rfc2392.txt.
> 
> Thanks for the pointer, but I find that document somewhat disappointing.
> 
> For one thing, I was confused by this:
> 
> 	A "cid" URL is converted to the corresponding Content-ID
> 	message header [MIME] by removing the "cid:" prefix,
> 	converting the % encoded character to their equivalent
> 	US-ASCII characters, and enclosing the remaining parts with an
> 	angle bracket pair, "<" and ">".  For example,
> 	"cid:foo4%25foo1@bar.net" corresponds to
> 
> 	    Content-ID: <foo4%25foo1@bar.net>
> 
> Shouldn't "%25" have been converted to "%":
> 
> 	Content-ID: <foo4%foo1@bar.net>

Yes, it should, as it was correctly written in the older version
at http://www.ietf.org/rfc/rfc2111.txt.

> But more importantly, the mid and cid URLs do not actually specify a
> LOCATION: that makes them more like a URN than a URL.

Yes, I agree that mid and cid could be rather defined as URN,
e.g. urn:mid:foo@bar.net.  However, according to the contemporary view
(http://www.w3.org/TR/uri-clarification/) the distinction between
URL and URN is blurred now.

> And it makes them similar to the news:<message-id> URL scheme.  But
> there is also a nntp://<host>:<port>/<newsgroup>/<article> URL
> scheme, which I think is closer to what we need.
> 
> > Then, for example, opening the link <mid:3F9471FB.4000609@yahoo.com>
> > should start a mail reader, find corresponding message by its
> > Message-ID, prepare article buffer and switch to it (e.g. in case
> > of Gnus to call the function `gnus-summary-goto-article'; other
> > mail readers should have a similar function).
> 
> Shouldn't the cid and mid schemes specify a location via the Common
> Internet Scheme Syntax defined in RFC 1738?  That way, you could
> specify a folder file, or a POP or IMAP server (and user and
> password).
> 
> We could define separate URL schemes for mbox, POP, and IMAP access,
> but I think for now I'm going to pursue my origial idea, but rename
> it to conform to the standard for experimental schemes:
> 
> x-mid:[//[user@]host]/path/to/folder#message-id

I think it's impossible to define such generic URL scheme,
because messages can be accessed only by mail agents,
but every mail agent has its own message location schemes.

> > I'm not sure yet, where this could be implemented: url.el is not
> > part of Emacs (BTW: Why?); thingatpt.el mentions this protocol
> > name, but that's all; perhaps this should be done partially in
> > ffap.el.
> 
> As long as it respects the read-mail-command variable.  To do that
> correctly, I think we would need to define an interface like
> compose-mail that would accept all the arguments that might be
> necessary to specify a message (folder file and format; or server,
> protocol, user, and password; plus message id); then a new utility
> define-read-mail-command (analogous to define-mail-user-agent) that
> would associate each read-mail-command to a function that supports
> that interface.
> 
> Otherwise, how would Emacs know where to search for the Message-Id?

It is a good idea to define an interface like `compose-mail'.
But I think it's enough to specify only Message-Id to unambiguously
find a needed message:

(defun goto-mail (&optional message-id)
  (interactive "sMessage-Id: ")
  (let ((function (get read-mail-command 'gotofunc)))
    (and function (funcall function message-id))))

Now, the main problem is how to implement a user-agent specific
functions that will look up the message by its Message-Id.  Gnus has
the function `gnus-summary-goto-article' (which currently works only
within the selected folder).  Does a similar function exist in rmail?

-- 
http://www.jurta.org/emacs/

customizing a variable named in Info

[Peter S Galbraith]

Forgive the intrusion, this is perhaps the wrong list for a feature
request.

It would be nice to have a way to identity an Emacs variable in texinfo
sources such that when Emacs Info renders the page it can make the
variable name clickable in order to customize it.  (I know texinfo is
not limited to documenting Emacs, so this would probably be a secret
handshake of some sort that Emacs could parse.)

I find myself writing docs that often say things like "if you wish to
enable this feature, customize the variable `foobar'.

I know I can put point on the string, do `C-h v' and then click on
customize, but such a feature would make customizable variables stand
out and the documentation would therefore render the information in a
more efficient way (specially for new users).

Thanks,
-- 
Peter S. Galbraith <p.galbraith@globetrotter.net>
GPG key 1024/D2A913A1 - 97CE 866F F579 96EE  6E68 8170 35FF 799E
6623'rd GNU/Linux user at the Counter - http://counter.li.org/

Re: customizing a variable named in Info

[Eli Zaretskii]

> Date: Sat, 18 Oct 2003 21:34:28 -0400
> From: Peter S Galbraith <p.galbraith@globetrotter.net>
> 
> It would be nice to have a way to identity an Emacs variable in texinfo
> sources such that when Emacs Info renders the page it can make the
> variable name clickable in order to customize it.

I think this is a good idea, but it needs to be elaborated a bit in
order to discuss its merits.

For example, do you want _every_ instance of a variable's name in the
manual to be clickable like that?  That could be a bit annoying.  If
only some instances should be clickable, how do we tell Info which
ones?

Also, how would Info know which symbol is a variable?  Variable names
have the @code markup, which they share with all other symbols:
functions, commands, X resources, environment variable names, etc.  I
think we might need a new Texinfo directive for this.  Or we could
have makeinfo generate something special for a variable mentioned in
a paragraph that has a @vindex entry before it.

> I know I can put point on the string, do `C-h v' and then click on
> customize, but such a feature would make customizable variables stand
> out and the documentation would therefore render the information in a
> more efficient way (specially for new users).

Perhaps some shorter procedure, like a key binding for "customize the
variable at point", would do?

Re: customizing a variable named in Info

[Luc Teirlinck]

Eli Zaretskii wrote:

   > Date: Sat, 18 Oct 2003 21:34:28 -0400
   > From: Peter S Galbraith <p.galbraith@globetrotter.net>
   > 
   > It would be nice to have a way to identity an Emacs variable in texinfo
   > sources such that when Emacs Info renders the page it can make the
   > variable name clickable in order to customize it.

   I think this is a good idea, but it needs to be elaborated a bit in
   order to discuss its merits.

I have not yet thought of the following long enough really, but I just
want to point it out before people start to pursue possibly more
complex and less unifying avenues, that could require more work.

There would appear to be the possibility of using `help-make-xrefs',
which does something similar in *Help* buffers, stripped of its
*Help*-buffer specific aspects.  That would make the conventions for
Info the same as the ones for *Help* buffers, preventing both users
and Elisp programmers from getting confused by subtle and unnecessary
differences between both.  That would affect not only variables, but
also functions and, if preceded or followed by the word `face', also
faces.  Indeed, we are not just talking about access to customization,
but also information.  Moreover, faces are customizable too.  Note that
the making of hyperlinks in *Help* buffers has become somewhat more
conservative since yesterday evening.

Since all of this only makes sense for Info manuals dealing with
Elisp, this feature would only be activated by, say, a file local
variable or something similar.  It should not apply to all info files
by default, since for many of them it would make no sense.

   Or we could have makeinfo generate something special for a variable
   mentioned in a paragraph that has a @vindex entry before it.

Makes no sense unless we are talking about an _Elisp_ variable.
`@vindex' by no means guarantees this.  Even then, the variable
documentation might not be available unless the reader is reading Info
using Emacs.

   > I know I can put point on the string, do `C-h v' and then click on
   > customize, but such a feature would make customizable variables stand
   > out and the documentation would therefore render the information in a
   > more efficient way (specially for new users).

   Perhaps some shorter procedure, like a key binding for "customize the
   variable at point", would do?

I believe that Peter wants the variable to "stand out better", which
the `help-make-xrefs' derivative would do by underlining.

Sincerely,

Luc.

Re: customizing a variable named in Info

[Peter S Galbraith]

Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> Eli Zaretskii wrote:
> 
>    > Date: Sat, 18 Oct 2003 21:34:28 -0400
>    > From: Peter S Galbraith <p.galbraith@globetrotter.net>
>    > 
>    > I know I can put point on the string, do `C-h v' and then click on
>    > customize, but such a feature would make customizable variables stand
>    > out and the documentation would therefore render the information in a
>    > more efficient way (specially for new users).
> 
>    Perhaps some shorter procedure, like a key binding for "customize the
>    variable at point", would do?
> 
> I believe that Peter wants the variable to "stand out better", which
> the `help-make-xrefs' derivative would do by underlining.

Exactly.

I'm glad I brought this up.  Luc's points about functions, faces and a
consistent interface with *Help* buffers makes sense.

Peter

Re: customizing a variable named in Info

[Richard Stallman]

    It would be nice to have a way to identity an Emacs variable in texinfo
    sources such that when Emacs Info renders the page it can make the
    variable name clickable in order to customize it.

In Texinfo, we use @code for variables and for functions, and for
other things.  You could imagine arranging to make @code cause Emacs
to check whether the name is a function, and whether it is a variable.
But this would require a change in Info format, which would be a real
pain.

Another idea is that Emacs Info could do something special when it is
looking at a manual that concerns Emacs, driven by the textual
context.  If it uses the existing format of Texinfo files, we only
need some convention for a magic cookie to put in the manual to enable
this feature.  The only hard part is to implement the feature in Emacs
Info.

Please work on it if you feel the urge.

doc elisp intro cross reference fixes

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

        * emacs-lisp-intro.texi: Corrections to cross references,
        (Interactive Options): elisp "interactive" -> "Using Interactive".
        (defvar and asterisk): Remove emacs "Edit Options" reference,
        edit-options is no longer described in the emacs manual.
        (Lists diagrammed): elisp "List Type" -> "Cons Cell Type".


[-- Attachment #2: emacs-lisp-intro.texi.xref.diff --]
[-- Type: text/plain, Size: 2385 bytes --]

*** emacs-lisp-intro.texi.~1.22.~	Thu Jan  1 10:00:01 1970
--- emacs-lisp-intro.texi	Fri Nov 14 14:57:00 2003
***************
*** 3519,3525 ****
  
  Alternatively, if the special letter-codes are not right for your
  application, you can pass your own arguments to @code{interactive} as
! a list.  @xref{interactive, , Using @code{Interactive}, elisp, The
  GNU Emacs Lisp Reference Manual}, for more information about this advanced
  technique.
  
--- 3519,3525 ----
  
  Alternatively, if the special letter-codes are not right for your
  application, you can pass your own arguments to @code{interactive} as
! a list.  @xref{Using Interactive, , Using @code{Interactive}, elisp, The
  GNU Emacs Lisp Reference Manual}, for more information about this advanced
  technique.
  
***************
*** 8097,8104 ****
  
  For me, the major use of the @code{edit-options} command is to suggest
  variables that I might want to set in my @file{.emacs} file.  I urge
! you to look through the list.  (@xref{Edit Options, , Editing Variable
! Values, emacs, The GNU Emacs Manual}.)
  
  @node copy-region-as-kill, cons & search-fwd Review, defvar, Cutting & Storing Text
  @comment  node-name,  next,  previous,  up
--- 8097,8103 ----
  
  For me, the major use of the @code{edit-options} command is to suggest
  variables that I might want to set in my @file{.emacs} file.  I urge
! you to look through the list.
  
  @node copy-region-as-kill, cons & search-fwd Review, defvar, Cutting & Storing Text
  @comment  node-name,  next,  previous,  up
***************
*** 9142,9148 ****
  and the second of which holds the address of @code{buttercup}.
  
  A pair of address-boxes is called a @dfn{cons cell} or @dfn{dotted
! pair}.  @xref{List Type, , List Type , elisp, The GNU Emacs Lisp
  Reference Manual}, and @ref{Dotted Pair Notation, , Dotted Pair
  Notation, elisp, The GNU Emacs Lisp Reference Manual}, for more
  information about cons cells and dotted pairs.
--- 9141,9147 ----
  and the second of which holds the address of @code{buttercup}.
  
  A pair of address-boxes is called a @dfn{cons cell} or @dfn{dotted
! pair}.  @xref{Cons Cell Type, , Cons Cell and List Types, elisp, The GNU Emacs Lisp
  Reference Manual}, and @ref{Dotted Pair Notation, , Dotted Pair
  Notation, elisp, The GNU Emacs Lisp Reference Manual}, for more
  information about cons cells and dotted pairs.

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: doc elisp intro cross reference fixes

[Juri Linkov]

Kevin Ryde <user42@zip.com.au> writes:
>         * emacs-lisp-intro.texi: Corrections to cross references,
>         (Interactive Options): elisp "interactive" -> "Using Interactive".
>         (defvar and asterisk): Remove emacs "Edit Options" reference,
>         edit-options is no longer described in the emacs manual.
>         (Lists diagrammed): elisp "List Type" -> "Cons Cell Type".

The edit-options command is no longer described in the emacs manual,
because it is obsolete now.  Perhaps emacs-lisp-intro shouldn't
suggest obsolete packages, so all these three paragraphs about
edit-options should be removed from emacs-lisp-intro.

BTW, does such an Emacs package exist that finds broken links in Info
documents like HTML link checkers do?  I already manually found
some broken links in the Emacs manual, but want to find all of them.

-- 
http://www.jurta.org/emacs/

Re: doc elisp intro cross reference fixes

[Robert J. Chassell]

Juri Linkov <juri@jurta.org> wrote

    The edit-options command is no longer described in the emacs
    manual, because it is obsolete now.  Perhaps emacs-lisp-intro
    shouldn't suggest obsolete packages, so all these three paragraphs
    about edit-options should be removed from emacs-lisp-intro.

This is a good idea.  I have commented out the three paragraphs in 
emacs/lispintro/emacs-lisp-intro.texi 

    (eintr)defvar and asterisk

Next time you `make info dvi html' the surface representations should
be updated.

Is the main point of the node still accurate?

    When you specified a variable using the @code{defvar} special
    form, you could distinguish a readily settable variable from
    others by typing an asterisk, @samp{*}, in the first column of its
    documentation string.  ....

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: doc elisp intro cross reference fixes

[Juri Linkov]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> Juri Linkov <juri@jurta.org> wrote
>     The edit-options command is no longer described in the emacs
>     manual, because it is obsolete now.  Perhaps emacs-lisp-intro
>     shouldn't suggest obsolete packages, so all these three paragraphs
>     about edit-options should be removed from emacs-lisp-intro.
>
> This is a good idea.  I have commented out the three paragraphs in 
> emacs/lispintro/emacs-lisp-intro.texi 
>
>     (eintr)defvar and asterisk
>
> Next time you `make info dvi html' the surface representations should
> be updated.
>
> Is the main point of the node still accurate?
>
>     When you specified a variable using the @code{defvar} special
>     form, you could distinguish a readily settable variable from
>     others by typing an asterisk, @samp{*}, in the first column of its
>     documentation string.  ....

Yes, this point is still accurate.  However, I'd like to propose a
better alternative for the above mentioned three paragraphs: to replace
in those three paragraphs the command `edit-options' by its valid
equivalent `set-variable'.  Sorry, I didn't propose this earlier,
this idea came to me just now.

===================================================================
@noindent
This means that you could (and still can) use the @code{set-variable}
command to change the value of
@code{shell-command-default-error-buffer} temporarily.

@findex set-variable
However, options set using @code{set-variable} are set only for the
duration of your editing session.  The new values are not saved
between sessions.  Each time Emacs starts, it reads the original
value, unless you change the value within your @file{.emacs} file,
either by setting it manually or by using @code{customize}.
@xref{Emacs Initialization, , Your @file{.emacs} File}.

For me, the major use of the @code{set-variable} command is to suggest
variables that I might want to set in my @file{.emacs} file.  I urge
you to look through the list.
===================================================================

Seems this last paragraph should be improved to tell that full list
of user options can be displayed by pressing the tab character in the
minibuffer after calling the `M-x set-variable' command.

-- 
http://www.jurta.org/emacs/

Re: doc elisp intro cross reference fixes

[Robert J. Chassell]

Juri Linkov <juri@jurta.org> wrote:

    I'd like to propose a better alternative ... replace in those
    three paragraphs the command `edit-options' by its valid
    equivalent `set-variable'.

Done.  Good idea.  I also mentioned the use of TAB to see the
completion list.

`defcustom' is discussed in       (eintr)defcustom  

While I think I said enough on `defcustom' for this book, I hardly use
the function.  I would appreciate a look by people with more
experience.

I committed the new version of emacs-lisp-intro.texi to CVS.  Next
time you `make info dvi html' the surface expressions should update.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    Is the main point of the node still accurate?

	When you specified a variable using the @code{defvar} special
	form, you could distinguish a readily settable variable from
	others by typing an asterisk, @samp{*}, in the first column of its
	documentation string.  ....

The use of the * is not obsolete, but it is vital also to document
proper use of defcustom.

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> The use of the * is not obsolete, but it is vital also to document
> proper use of defcustom.

Could someone explain to me the subtle differences between:
- defvar with a * in the docstring.
- defcustom with no * in the docstring.
- defcustom with a * in the docstring.


        Stefan

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   Could someone explain to me the subtle differences between:
   - defvar with a * in the docstring.

Customizable through `set-variable', but not through Custom.

   - defcustom with no * in the docstring.

Customizable through Custom, not with `set-variable'.  Usually
necessary if setting the variable directly has no effect.

   - defcustom with a * in the docstring.

Customizable through both.

Of the three the one that is not obviously useful is the first.  But
there are (infrequent) situations where it might seem reasonable.

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>    - defcustom with no * in the docstring.
> Customizable through Custom, not with `set-variable'.  Usually
> necessary if setting the variable directly has no effect.

BZZT!  Thanks for playing!
After (defcustom foobar 1 "hello"), set-variable is quite happy to let me
set the variable `foobar'.

Also could someone explain to me the point of having a variable that can be
set via set-variable but not via custom ?


        Stefan

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   After (defcustom foobar 1 "hello"), set-variable is quite happy to let me
   set the variable `foobar'.

Indeed, I was wrong on that one.  Here is the (I believe) correct
answer to when to use or not to use * in a defcustom (from
(elisp)Documentation Tips):

   * A variable's documentation string should start with `*' if the
     variable is one that users would often want to set interactively.
     If the value is a long list, or a function, or if the variable
     would be set only in init files, then don't start the
     documentation string with `*'.  *Note Defining Variables::.

One might nevertheless want to allow users to customize variables of
the latter type through Custom.

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>    After (defcustom foobar 1 "hello"), set-variable is quite happy to let me
>    set the variable `foobar'.
> Indeed, I was wrong on that one.

So what *is* the difference between defcustom with and without a * ?
AFAIK, there isn't any.


        Stefan

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   After (defcustom foobar 1 "hello"), set-variable is quite happy to
   let me set the variable `foobar'.

On second thought, I believe that is a bug.

>From (elisp)Variable Definitions:

 - Macro: defcustom option default doc [keyword value]...
     Declare OPTION as a customizable user option variable.  Do not
     quote OPTION.  The argument DOC specifies the documentation
     string for the variable.  It should often start with a `*' to
     mark it as a "user option" (*note Defining Variables::).  Do not
     start the documentation string with `*' for options which cannot
     or normally should not be set with `set-variable'; examples of
     the former are global minor mode options such as
     `global-font-lock-mode' and examples of the latter are hooks.


Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>    After (defcustom foobar 1 "hello"), set-variable is quite happy to
>    let me set the variable `foobar'.

> On second thought, I believe that is a bug.

It's clearly not a bug.  A misfeature maybe, but not a bug since code
was written explicitly for it.

Anyway my point is that the difference between defcustom with and without
a * is in practice absent and in theory much too subtle and debatable to
justify its existence (after all, who knows whether users will want to set
something interactively or only at startup).
I suggest we just get rid of the distinction altogether.


        Stefan

Re: doc elisp intro cross reference fixes

[Kevin Rodgers]

Stefan Monnier wrote:

>>   After (defcustom foobar 1 "hello"), set-variable is quite happy to
>>   let me set the variable `foobar'.
> 
>>On second thought, I believe that is a bug.
> 
> It's clearly not a bug.  A misfeature maybe, but not a bug since code
> was written explicitly for it.


The code you're referring to is Fuser_variable_p, right?


> Anyway my point is that the difference between defcustom with and without
> a * is in practice absent and in theory much too subtle and debatable to
> justify its existence (after all, who knows whether users will want to set
> something interactively or only at startup).
> 

> I suggest we just get rid of the distinction altogether.


I disagree.  It is a useful distinction, and programmers can take
advantage of it to prevent users from setting variables in a way that
they shouldn't (and thence submitting bug reports when they don't get
the desired effect).

I don't find the explanation of Variable Definitions in the Emacs Lisp
manual that Luc cited to be too subtle.  And I don't understand what
startup vs. session time has to do with it: it only has to do with
whether set-variable can be used interactively.

set-variable and customize are independent mechanisms that are enabled
by a doc string convention and the custom-* symbol properties
respectively, and as a programmer I'd like to retain control over those
mechanisms.

-- 
Kevin Rodgers

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> I disagree.  It is a useful distinction, and programmers can take
> advantage of it to prevent users from setting variables in a way that
> they shouldn't (and thence submitting bug reports when they don't get
> the desired effect).

Can you give concrete examples where the distinction makes sense ?

> I don't find the explanation of Variable Definitions in the Emacs Lisp
> manual that Luc cited to be too subtle.

How many elisp programmers know about it and understand it ?

> And I don't understand what startup vs. session time has to do with it:
> it only has to do with whether set-variable can be used interactively.

That was the distinction proposed by Luc.

> set-variable and customize are independent mechanisms that are enabled
> by a doc string convention and the custom-* symbol properties
> respectively, and as a programmer I'd like to retain control over those
> mechanisms.

Why should they be independent mechanisms ?
What is the benefit ?  Why should something be only allowed via M-x
customize-variable but not via M-x set-variable (and vice-versa, BTW) ?

As a programmer, the distinction seems very faint and I have a hard time
coming up with cases where it could make sense to prevent one use
and allow the other.

As a user it just makes for inconsistency where some variables can be set
via M-x set-variable while others need M-x customize-variable.


        Stefan

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   > And I don't understand what startup vs. session time has to do with it:
   > it only has to do with whether set-variable can be used interactively.

   That was the distinction proposed by Luc.

I did not "propose" anything.  I quoted current standards from the
Elisp manual.  There are (combining both quotes) at least three
reasons not to use `*' in a defcustom (but they combine to one more
general reason):

1.  Setting the variable with set-variable would not have any effect
    other than maybe to confuse Emacs internals or the user.  This is
    probably the main reason.

2.  The value is long and/or complex and specifying or editing it in
    the minibuffer is going to be awkward.

3.  It would be set only in init files.  This is one that is
    apparently not followed consistently at
    all. `inhibit-startup-message' has a `*' in its documentation
    string.  I doubt that setting it interactively with set-variable
    is going to have a lot of effect.  Anybody trying to do so is
    probably mistakenly believing that it is going to affect future
    sessions.

Basically, everything can be summarized with: "use `*' if and only if
setting the variable with `set-variable' makes sense".  I should say
that the fact set-variable itself will indeed not distinguish (not even
for completion) between `*' or no `*' is not very consistent with
this.

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> 1.  Setting the variable with set-variable would not have any effect
>     other than maybe to confuse Emacs internals or the user.  This is

Sounds like a bug: if it works via customize-variable, there's not good
reason why it can't work with set-variable.

> 2.  The value is long and/or complex and specifying or editing it in
>     the minibuffer is going to be awkward.

That's a fringe case that nobody has ever complained about, so it's
clearly not a big deal.  In other words: no harm.

> 3.  It would be set only in init files.  This is one that is
>     apparently not followed consistently at
>     all. `inhibit-startup-message' has a `*' in its documentation
>     string.  I doubt that setting it interactively with set-variable
>     is going to have a lot of effect.  Anybody trying to do so is
>     probably mistakenly believing that it is going to affect future
>     sessions.

And here's an example of my claim that programmers don't understand the
distinction.

> Basically, everything can be summarized with: "use `*' if and only if
> setting the variable with `set-variable' makes sense".  I should say
> that the fact set-variable itself will indeed not distinguish (not even
> for completion) between `*' or no `*' is not very consistent with

And the fact that nobody has ever complained about the fact that
set-variable can be used on vars that don't have a * (as long as they're
defined with `defcustom') indicates that it is not a bad behavior.


        Stefan

Re: doc elisp intro cross reference fixes

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > 1.  Setting the variable with set-variable would not have any effect
> >     other than maybe to confuse Emacs internals or the user.  This is
> 
> Sounds like a bug: if it works via customize-variable, there's not good
> reason why it can't work with set-variable.

There are reasons.  Customize can specify actions to do whenever a
variable is set (there are a few customizable variables that switch on
minor modes, for example).  Also when variables have a complex
structure, it is a bit of policy to say "this 20-element list does not
make sense setting via set-variable".

> > Basically, everything can be summarized with: "use `*' if and only
> > if setting the variable with `set-variable' makes sense".  I
> > should say that the fact set-variable itself will indeed not
> > distinguish (not even for completion) between `*' or no `*' is not
> > very consistent with
> 
> And the fact that nobody has ever complained about the fact that
> set-variable can be used on vars that don't have a * (as long as
> they're defined with `defcustom') indicates that it is not a bad
> behavior.

And the fact that nobody has ever complained about undiscovered
crimes indicates that they are not a bad thing...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>> > 1.  Setting the variable with set-variable would not have any effect
>> >     other than maybe to confuse Emacs internals or the user.  This is
>> 
>> Sounds like a bug: if it works via customize-variable, there's not good
>> reason why it can't work with set-variable.

> There are reasons.  Customize can specify actions to do whenever a
> variable is set (there are a few customizable variables that switch on
> minor modes, for example).

That's what he said, basically and I replied that it's a bug in
set-variable.  For such vars, set-variable should either put a big warning
or do the same as customize-variable (i.e. call the setter function).

> Also when variables have a complex structure, it is a bit of policy to say
> "this 20-element list does not make sense setting via set-variable".

If it's too inconvenient for a user, he just won't use set-variable with it.
The user can do this part of the policing himself.  There's no need
to introduce a distinction between two sorts of user-variables just because
some are hard to change using one of the two interfaces.

>> > Basically, everything can be summarized with: "use `*' if and only
>> > if setting the variable with `set-variable' makes sense".  I
>> > should say that the fact set-variable itself will indeed not
>> > distinguish (not even for completion) between `*' or no `*' is not
>> > very consistent with
>> 
>> And the fact that nobody has ever complained about the fact that
>> set-variable can be used on vars that don't have a * (as long as
>> they're defined with `defcustom') indicates that it is not a bad
>> behavior.

> And the fact that nobody has ever complained about undiscovered
> crimes indicates that they are not a bad thing...

Sorry, but absurd analogies do not count as an argument in my book,
especially not if they resort to things like crime, nazism, etc...


        Stefan

Re: doc elisp intro cross reference fixes

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> >> 
> >> And the fact that nobody has ever complained about the fact that
> >> set-variable can be used on vars that don't have a * (as long as
> >> they're defined with `defcustom') indicates that it is not a bad
> >> behavior.
> 
> > And the fact that nobody has ever complained about undiscovered
> > crimes indicates that they are not a bad thing...
> 
> Sorry, but absurd analogies do not count as an argument in my book,
> especially not if they resort to things like crime, nazism, etc...

So let me put this without any analogy: I fail to see that merely
because it took a while to discover a bug (and a discrepancy between
documentation and behavior is a bug) this means that the bug is
correct behavior.

Most bugs go unnoticed or at least unrecorded for a long time.  That
does not make them desirable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>> >> And the fact that nobody has ever complained about the fact that
>> >> set-variable can be used on vars that don't have a * (as long as
>> >> they're defined with `defcustom') indicates that it is not a bad
>> >> behavior.
>> 
>> > And the fact that nobody has ever complained about undiscovered
>> > crimes indicates that they are not a bad thing...
>> 
>> Sorry, but absurd analogies do not count as an argument in my book,
>> especially not if they resort to things like crime, nazism, etc...

> So let me put this without any analogy: I fail to see that merely
> because it took a while to discover a bug (and a discrepancy between
> documentation and behavior is a bug) this means that the bug is
> correct behavior.

Then we misunderstood each other: I completely agree that the discrepancy is
a bug and this discussion is an attempt to fix it.  In the first paragraph
quoted above you can see that I am arguing that the behavior is not a bug,
thus meaning that the bug is in the documentation.

> Most bugs go unnoticed or at least unrecorded for a long time.
> That does not make them desirable.

Sure, but I was not talking about a bug: just about a behavior.


        Stefan

Re: doc elisp intro cross reference fixes

[Kevin Rodgers]

David Kastrup wrote:

> So let me put this without any analogy: I fail to see that merely
> because it took a while to discover a bug (and a discrepancy between
> documentation and behavior is a bug) this means that the bug is
> correct behavior.
> 
> Most bugs go unnoticed or at least unrecorded for a long time.  That
> does not make them desirable.

Hear, hear!

-- 
Kevin Rodgers

Re: doc elisp intro cross reference fixes

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> >> > 1.  Setting the variable with set-variable would not have any effect
> >> >     other than maybe to confuse Emacs internals or the user.  This is
> >> 
> >> Sounds like a bug: if it works via customize-variable, there's not good
> >> reason why it can't work with set-variable.
> 
> > There are reasons.  Customize can specify actions to do whenever a
> > variable is set (there are a few customizable variables that switch on
> > minor modes, for example).
> 
> That's what he said, basically and I replied that it's a bug in
> set-variable.  For such vars, set-variable should either put a big
> warning or do the same as customize-variable (i.e. call the setter
> function).

If set-variable does not tend to consult the "customize" data
structures in other circumstances, it would be unexpected if it did
in this case.  I do seem to remember, though, that set-variable
declined setting a variable to values opposed to any possibly
customize declaration.  So perhaps making set-variable do pretty much
the "set for current session" operation procedure of customize would
be sensible behavior.

That does not imply that the current behavior would be a bug, simply
that it might make sense to change it (along with its documentation).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> If set-variable does not tend to consult the "customize" data
> structures in other circumstances, it would be unexpected if it did
> in this case.  I do seem to remember, though, that set-variable
> declined setting a variable to values opposed to any possibly
> customize declaration.  So perhaps making set-variable do pretty much
> the "set for current session" operation procedure of customize would
> be sensible behavior.

> That does not imply that the current behavior would be a bug, simply
> that it might make sense to change it (along with its documentation).

It's a user-level operation which is likely in those circumstances not to
do what the user intended to do.  It qualifies as a bug (although probably
minor) for me.
The user should at least be made aware of the problem (at the very least
in the manual).


        Stefan

Re: doc elisp intro cross reference fixes

[Kevin Rodgers]

David Kastrup wrote:

> If set-variable does not tend to consult the "customize" data
> structures in other circumstances, it would be unexpected if it did
> in this case.


But it already does, via user-variable-p (when called interactively), which
used to restrict the user to *-documented symbols but now also allows symbols
with custom properties.  (Stefan thinks that's an improvement, but I think
custom variables should still have been required to have * doc strings.)

> I do seem to remember, though, that set-variable
> declined setting a variable to values opposed to any possibly
> customize declaration.


Yep, set-variable does use the symbol's custom-type property.

> So perhaps making set-variable do pretty much
> the "set for current session" operation procedure of customize would
> be sensible behavior.
> 
> That does not imply that the current behavior would be a bug, simply
> that it might make sense to change it (along with its documentation).


Why not just (defalias 'set-variable 'customize-variable) and be done with it?


-- 
Kevin Rodgers

Re: doc elisp intro cross reference fixes

[David Kastrup]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> David Kastrup wrote:

> > I do seem to remember, though, that set-variable
> > declined setting a variable to values opposed to any possibly
> > customize declaration.
> 
> 
> Yep, set-variable does use the symbol's custom-type property.
> 
> > So perhaps making set-variable do pretty much
> > the "set for current session" operation procedure of customize would
> > be sensible behavior.
> > That does not imply that the current behavior would be a bug, simply
> > that it might make sense to change it (along with its documentation).
> 
> 
> Why not just (defalias 'set-variable 'customize-variable) and be
> done with it?

Because I may want to experiment with several settings by using the
command line history of set-variable.  customize-variable, in
contrast, uses a widget hierarchy you have to wade through with TAB
and similar.

Quite different.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Why not just (defalias 'set-variable 'customize-variable) and be
> done with it?

It is an entirely different interface.

  (defalias 'set-variable 'customize-set-variable)

or 

  (defalias 'set-variable 'customize-set-value)

would make sense though.  The difference is that the first uses the
:set function, the later doesn't.

Both also set the 'customized-value' property so the variable will not
be flagged as "modified outside customize" later.

And they both will use the :prompt-value property of the custom type
(if any) to make the input smarter in some cases.

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> It is an entirely different interface.
>   (defalias 'set-variable 'customize-set-variable)
> or 
>   (defalias 'set-variable 'customize-set-value)
> would make sense though.  The difference is that the first uses the
> :set function, the later doesn't.

Indeed.  We'd just need to make (defvar a b "*c") equivalent
to (defcustom a b "c").


        Stefan

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote (in response to a quote from Per Abrahamsen):

   > It is an entirely different interface.
   >   (defalias 'set-variable 'customize-set-variable)
   > or 
   >   (defalias 'set-variable 'customize-set-value)
   > would make sense though.  The difference is that the first uses the
   > :set function, the later doesn't.

   Indeed.

Indeed which one?  These are two very different alternatives Per is
proposing.  From previous posts I would guess that you mean:

Indeed:  (defalias 'set-variable 'customize-set-variable)

Note that if you mean this literally, this is a non-trivial change in
as far as prefix arguments are concerned.  Right now, C-u set-variable
will set the buffer-local value.  After the defalias, it will set the
global value and prompt for a comment.  On the other hand,
customize-set-variable already accepts *-variables without defcustom.

   Indeed.  We'd just need to make (defvar a b "*c") equivalent
   to (defcustom a b "c").

You make this sound a lot simpler than it would be.  This will have to
be handled individually and very carefully for each *-defvar, a huge
amount of work.  If an author decided to use a *-defvar instead of a
defcustom, there probably is a good reason why he decided not to use a
defcustom.  For instance, default-enable-multibyte-characters has a
*-defvar.  You do not want to turn this into a defcustom, because it
would duplicate the defcustom for enable-multibyte-characters, which
also sets the default value.  That would be extremely confusing to the
Custom user.  Not only would blindly turning a *-defvar into a
defcustom be dangerous, it is impossible.  You will have to decide on
a :group, a :type and so on.

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>> It is an entirely different interface.
>> (defalias 'set-variable 'customize-set-variable)
>> or 
>> (defalias 'set-variable 'customize-set-value)
>> would make sense though.  The difference is that the first uses the
>> :set function, the later doesn't.
>    Indeed.
> Indeed which one?

Either: they both "would make sense".

> Indeed:  (defalias 'set-variable 'customize-set-variable)
> Note that if you mean this literally, this is a non-trivial change in
> as far as prefix arguments are concerned.

That doesn't mean it doesn't make sense.  It just means it has to be souped
up a little.  But that's a minor issue of coding: nothing compared to the
amount of work necessary to convince people on this list to accept the change
in behavior w.r.t whether or not there's a * in the docstring.

>    Indeed.  We'd just need to make (defvar a b "*c") equivalent
>    to (defcustom a b "c").

> You make this sound a lot simpler than it would be.  This will have to
> be handled individually and very carefully for each *-defvar, a huge
> amount of work.

Doesn't have to be done that way, does it ?

> If an author decided to use a *-defvar instead of a
> defcustom, there probably is a good reason why he decided not to use a
> defcustom.

In few very rare cases.

> For instance, default-enable-multibyte-characters has a
> *-defvar.  You do not want to turn this into a defcustom, because it
> would duplicate the defcustom for enable-multibyte-characters, which
> also sets the default value.

It's just another case of multiple name for the same var, as is the
case for all the default-* vars, right?
We can probably take care of this specially, if needed, although I must say
I don't see the harm is adding a "redundant" custom-var, as long as the
variable does not appear in any normal group and is thus only accessed via
M-x customize-variable or M-x set-variable or somesuch.

> That would be extremely confusing to the Custom user.

I'd expect most custom users would never even be confronted with
the potential for confusion.  And we can of course try and fix those things
as time goes: the important thing is that there is no real hurry.

> Not only would blindly turning a *-defvar into a
> defcustom be dangerous, it is impossible.

BZZT!  Thanks for playing, it works exactly as I showed: (defcustom a b "c")


        Stefan

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   BZZT!  Thanks for playing, it works exactly as I showed: (defcustom a b "c")

OK, but in which node of the Elisp manual is this feature documented?
Which node of the Elisp manual contains the guidelines on when it is
appropriate to use this feature?  The only answer to that question I
was able to find was in (elisp)Group Definitions.  This clearly
suggests to me that it is _never_ appropriate to use the "feature":

Each Emacs Lisp package should have one main customization group which
contains all the options, faces and other groups in the package.

My comments:

To me, this clearly says that every package containing defcustom's or
defface's should have a customization group and that _all_ options of
the package should be in that group or a subgroup of it.  If that
would not be the present standard, then the above sentence, quoted
from (elisp)Group Definitions, should be quantified.

Sincerely,

Luc.

`

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   I don't see the harm is adding a "redundant" custom-var, as long as the
   variable does not appear in any normal group and is thus only accessed via
   M-x customize-variable or M-x set-variable or somesuch.

One obvious harm could be two "dueling entries" in the
custom-set-variables form.

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    Indeed:  (defalias 'set-variable 'customize-set-variable)

    Note that if you mean this literally, this is a non-trivial change in
    as far as prefix arguments are concerned.  Right now, C-u set-variable
    will set the buffer-local value.

Yes, we would want to add a similar C-u feature to customize-set-variable
before doing this.

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Richard Stallman wrote:

       Indeed:  (defalias 'set-variable 'customize-set-variable)

       Note that if you mean this literally, this is a non-trivial change in
       as far as prefix arguments are concerned.  Right now, C-u set-variable
       will set the buffer-local value.

   Yes, we would want to add a similar C-u feature to customize-set-variable
   before doing this.

Note that the optional argument is not the only difference between
`customize-set-variable' and `set-variable'.  Differences if both are
called without optional argument on a variable VAR:

1.  If VAR already has a buffer-local binding `set-variable' sets that
    buffer-local binding _even_ when called without prefix argument.
    The prefix argument just guarantees that a buffer-local binding
    will be made if there was none before.  `custom-set-variable' sets
    the default value.

2.  If we enter a form in the minibuffer, set-variable uses the
    unevaluated value, custom-set-variable the evaluated value.

(See the ielm run below for examples.)

If we would merge the two functions into one, we have to decide
how to reconcile those two differences.

The buffer-local issue is more complex.

Currently there is a variable "custom-local-buffer".  It _only_ tries
to set a local value if the variable already has a local value, it
does not make a buffer-local binding itself.  It is essentially
undocumented and unsupported.  The necessary code to support it was
never installed and was lost.  There is some minimal supporting code
in `custom-set-default' and `custom-set-minor-mode', but in no other
part of Custom.  I grepped.  Not a single :set function (other than
the two mentioned ones) supports it.

That variable is more or less irrelevant to the issue at hand anyway.
The buffer current at the time will be the buffer from which
set-variable or custom-set-variable was called.

The problem is that :set functions usually are not written to deal
with buffer-local values.  The authors of :set functions are not to
blame for that, because (elisp)Customization does not mention
anything about dealing with buffer-local-values:

   The default for SETFUNCTION is `set-default'.

Hence, :set functions are supposed to generalize `set-default',
nothing buffer-local in sight.

Do we just ignore the :set function and use `set' when dealing with
buffer-local values?  Do we come up with a means to declare a :set
function "safe for buffer-local use" and call it if it satisfies that
criterion? 

Ielm run illustrating some of the above:

===File ~/set-var-ielm======================================
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (defvar aa 1 "*aha")
aa
ELISP> (make-variable-buffer-local 'aa)
aa
ELISP> (setq aa 2)
2
ELISP> ;; M-x set-variable RET aa RET (list (current-buffer) (point)) 
*** Read error ***  End of file during parsing
ELISP> aa
(list
 (current-buffer)
 (point))

ELISP> (default-value 'aa)
1
ELISP> ;; M-x custom-set-variable RET aa RET (list (current-buffer) (point)) 
*** Read error ***  End of file during parsing
ELISP> aa
(list
 (current-buffer)
 (point))

ELISP> (default-value 'aa)
(#<buffer *ielm*> 420)

ELISP> 
============================================================

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    Indeed:  (defalias 'set-variable 'customize-set-variable)

    Note that if you mean this literally, this is a non-trivial change in
    as far as prefix arguments are concerned.  Right now, C-u set-variable
    will set the buffer-local value.

Yes, we would want to add a similar C-u feature to customize-set-variable
before doing this.

       Indeed.  We'd just need to make (defvar a b "*c") equivalent
       to (defcustom a b "c").

    You make this sound a lot simpler than it would be.  This will have to
    be handled individually and very carefully for each *-defvar, a huge
    amount of work.

In the long run, we want to do that huge amount of work.
All of these variables should have appropriate custom types.
That is already on the agenda of work that should be done.

However, in the short run, we don't have to do this immediately.  It is
certainly possible to handle all defvars with * using a default custom type
that allows all Lisp objects as values.  That loses nothing compared with
the way things are now.

      If an author decided to use a *-defvar instead of a
    defcustom, there probably is a good reason why he decided not to use a
    defcustom.

I think the most common reason would be that the Lisp package is old.

      For instance, default-enable-multibyte-characters has a
    *-defvar.  You do not want to turn this into a defcustom, because it
    would duplicate the defcustom for enable-multibyte-characters, which
    also sets the default value.  That would be extremely confusing to the
    Custom user.

We could do something special for cases like these.

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

>From my previous message:

   Not only would blindly turning a *-defvar into a
   defcustom be dangerous, it is impossible.  You will have to decide on
   a :group, a :type and so on.

I said this too quickly, defcustom without :group indeed works.  It
just does not show up in a customization buffer (which it should not).

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   Indeed.  We'd just need to make (defvar a b "*c") equivalent
   to (defcustom a b "c").

In fact, people already seem to have used this "feature".  Just do

 M-x customize-group nil

Are these deliberate or inadvertent bugs?  Is this `nil' group a
deliberate feature or an unintentional oddity?  If this is a feature
should it not be mentioned in (elisp)Group Definitions?

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Are these deliberate or inadvertent bugs?  

It is just a buglet in a Gnus macro.

Evaluate this expression to get a list of variables declared with
defcustom but not in any group:

(let (found)
  (mapatoms (lambda (sym) 
              (let ((group (get sym 'custom-group)))
                (setq found (append group found)))))
  (mapatoms (lambda (sym)
              (and (get sym 'custom-type)
                   (not (assq sym found))
                   (insert (format "%S\n" sym))))))

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Per Abrahamsen wrote:

   Evaluate this expression to get a list of variables declared with
   defcustom but not in any group:

   (let (found)
     (mapatoms (lambda (sym) 
		 (let ((group (get sym 'custom-group)))
		   (setq found (append group found)))))
     (mapatoms (lambda (sym)
		 (and (get sym 'custom-type)
		      (not (assq sym found))
		      (insert (format "%S\n" sym))))))

There are two problems with this expression:

1.  (get sym 'custom-type) :

Not only are there defcustom's without a :group, there also sre
defcustom's without a :type :

ELISP> (get 'ada-tight-gvd-integration 'custom-type)
nil

2. A variable defined using a defcustom without a :group _is_ in a
   group, the `nil' group:

ELISP> (get nil 'custom-group)
((ada-tight-gvd-integration custom-variable)
 (nnimap-authinfo-file custom-variable)
 (nnimap-prune-cache custom-variable)
 (nntp-authinfo-file custom-variable))


Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

>From my previous message:

   ELISP> (get nil 'custom-group)
   ((ada-tight-gvd-integration custom-variable)
    (nnimap-authinfo-file custom-variable)
    (nnimap-prune-cache custom-variable)
    (nntp-authinfo-file custom-variable))

Actually, this only shows up after one does 

`M-x customize-group RET nil RET'

or similar

In the ielm run below, we have an emacs -q started from scratch.
We evaluate (symbol-plist 'nil) and get nil.  We do 
`M-x customize-browse' and evaluate again.  Then we do
`M-x customize-group RET nil RET' and evaluate a third time:

ELISP> (symbol-plist 'nil)
nil
ELISP> (symbol-plist 'nil)
(custom-loads
 (ada-xref nnimap nntp))

ELISP> (symbol-plist 'nil)
(custom-loads
 (ada-xref nnimap nntp)
 custom-group
 ((ada-tight-gvd-integration custom-variable)
  (nnimap-authinfo-file custom-variable)
  (nnimap-prune-cache custom-variable)
  (nntp-authinfo-file custom-variable)))

ELISP>

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> 1.  (get sym 'custom-type) :
>
> Not only are there defcustom's without a :group, there also sre
> defcustom's without a :type :

Try this instead:

(let (found)
  (mapatoms (lambda (sym) 
              (let ((group (get sym 'custom-group)))
                (setq found (append group found)))))
  (mapatoms (lambda (sym)
              (and (boundp sym)
                    (get sym 'standard-value)
                   (not (assq sym found))
                   (insert (format "%S\n" sym))))))

> 2. A variable defined using a defcustom without a :group _is_ in a
>    group, the `nil' group:

Nope.

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Per Abrahamsen wrote:
>
>    (let (found)
>      (mapatoms (lambda (sym) 
> 		 (let ((group (get sym 'custom-group)))
> 		   (setq found (append group found)))))
>      (mapatoms (lambda (sym)
> 		 (and (boundp sym)
> 		       (get sym 'standard-value)
> 		      (not (assq sym found))
> 		      (insert (format "%S\n" sym))))))
>
> This lists all kinds of variables that _do_ have a :group.  (Actually,
> I believe it lists all customizable variables.)

I get this list:

initial-scratch-message
mml2015-unabbrev-trust-alist
gnus-inhibit-mime-unbuttonizing
flyspell-default-dictionary
gnus-agent-expire-unagentized-dirs
mail-source-ignore-errors
nntp-authinfo-file
message-minibuffer-local-map
mml-signencrypt-style-alist

> Why does `M-x customize-group RET nil RET' work then?  If you evaluate:
>
> (defcustom a 4 "c")
>
> then the customizable variable `a' winds up listed there, together
> with the other four.

I don't get "a" in the nil group.  The only members of the nil group I
get is those explicitly put there by a buggy Gnus macro.

Maybe it is because I use an older Emacs.

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Well, in the code I submitted :group and :type were optional, and all
variables could be customized (declared with defcustom or not).  

These were all deliberate design choices.  Adding customize support to
your Emacs Lisp code should be an easy and gradual process:

  <http://www.dina.dk/~abraham/custom/old-custom.html>


Heh.

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

David Kastrup <dak@gnu.org> writes:

> The purpose of customize is not to make things just sexp when they
> get complicated.  It is exactly when things get complicated that the
> user needs to be lead by his hand.

You can't make complicated stuff simple by adding a better UI.  This
is why I advocate keeping user options as simple as possible.

In any case, the point is that it is never an error to use "sexp" as
the customization type.  Although it might stylistically be cleaner to
leave out the the :type parameter if the option doesn't really accept
any sexp.  It won't matter, as the default for :type is sexp anyway.

Creating structured customization types for recursive data types is
possible, but very difficult.  I believe I finally got through with
the "make defining (recursive) widgets easy" helper widget I have been
attempting tp create for a decade.  I'll send that in a seperate
messsage.

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    2. A variable defined using a defcustom without a :group _is_ in a
       group, the `nil' group:

Isn't it a bug for a defcustom to lack a :group?

I'm not saying that case should get an error.  Perhaps putting
it in the `nil' group is a useful way to find these cases
so we can fix them.  But shouldn't they all be changed
to have groups?

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     2. A variable defined using a defcustom without a :group _is_ in a
>        group, the `nil' group:
>
> Isn't it a bug for a defcustom to lack a :group?

It was never intended for that case to be a bug.

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Also, I believe that if it is legitimate,

I don't see it as black and white.  I see it as better that a user
option is declared with defcustom than with defvar, even if the "var"
to "custom" is the only change.  

And I don't really see it is as a case where "legitimate" is proper
word to use.  Nothing breaks if the option is in no group.  And nobody
benefits from having the option in a poorly chosen group, it may even
be noise to users of that group.  Emacs is way to big to find anything
by browsing all customization groups.

So I think we should recommend people to use defcustom for user
options, and recommend them to put these options somewhere in the
customize group hierarchy where they will be likely be found by those
looking for it, and not be noise for those not interested.

It's an area for good judgement, not technical rules.

I don't know what the idea was behind trying to "guess" a
customization group, so I won't comment on that.

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> But, first of all, do we want to do (1) or (2)?

I'd vote (0): if there is no group specified, don't put it in any
group. 

The option may very well end up in a group anyway (explicit call to
custom-add-to-group or the second argument to defgroup), but if it
doesn't don't worry about it.  Having options that aren't in any group
doesn't break anything, and we have already spend way to much energy
on this non-problem.

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Per Abrahamsen wrote:

   I'd vote (0): if there is no group specified, don't put it in any
   group.

That is exactly what I described under (1).

   The option may very well end up in a group anyway (explicit call to
   custom-add-to-group or the second argument to defgroup), but if it
   doesn't don't worry about it.

I somehow forgot about those possibilities.  There is, at closer
reading, indeed nothing, even in the current Elisp manual, that says
that a defcustom should have a :group.  The manual seems to suggest
that every option should wind up in at least one group (which can
indeed be achieved in a variety of ways, it does not have to be done
by specifying :group), and even that suggestion could be reversed.

   Having options that aren't in any group doesn't break anything, and
   we have already spend way to much energy on this non-problem.

If nothing else, there is still one problem we have to take care of,
namely the change mentioned in the NEWS:

    ** defcustom and other custom declarations now use a default group
    (the last group defined in the same file) when no :group was given.

This change should be reversed.

Not only does it not take custom-add-to-group and the second argument
to defcustom into account, it clearly assumes that even the most
inappropriate group is better than no group whatsoever.

If somebody would have chosen a group for `eval-expression-print-level',
`kill-read-only-ok' or `yank-excluded-properties', using one of the
alternative (and documented) possibilities, then there would have been
no reason to put them in the "paren-blinking" group too, just to make
absolutely sure that they are in at least one group.  Seeing such options
in the "paren-blinking" group would be confusing to the Custom user.

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> But shouldn't every defcustom be part of some meaningful group?
> It seems to me that they all should.

Depends on the value of "should".  It is closer to "ought" than to "must".

I'd say having one (or more) well chosen ":group"s is at the same
level of importance as following the conventions for doc strings.

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    I'd say having one (or more) well chosen ":group"s is at the same
    level of importance as following the conventions for doc strings.

Any doc string that doesn't follow the conventions definitely should
be fixed.

So let's add a compiler warning for a defcustom that has nil for its group.

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Indeed.  We'd just need to make (defvar a b "*c") equivalent
> to (defcustom a b "c").

I'd prefer to add a warning to the compiler for (defvar a b "*c"),
with a suggestion to use (defcustom a b "c") instead.

And then fix the warnings.

Re: doc elisp intro cross reference fixes

[Richard Stallman]

Now I'm pretty well convinced that we can replace the * convention with
defcustom.  Does anyone want to argue against that?

If we do this, then for compatibility's sake, we should do something in
defvar so that variables defined with defvar and using a * in the doc
string become customizable.

    It is an entirely different interface.

      (defalias 'set-variable 'customize-set-variable)

    or 

      (defalias 'set-variable 'customize-set-value)

    would make sense though.  The difference is that the first uses the
    :set function, the later doesn't.

If we do something like this, I think we would want to use the :set
function, since that's the main reason for proposing such a change.

Does anyone see a reason not to make set-variable
equivalent to customize-set-variable?

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> Does anyone see a reason not to make set-variable
> equivalent to customize-set-variable?

Someone (MIles?) pointed out the the interface was different.  A
prefix argument to set-variable means "set buffer local value", while
a prefix argument to customize-set-variable means "add a customization
comment".

I'd suggest we change customize-set-variable so a prefix argument
means "set buffer local value".  I'd suspect that people who want to
add comments to their customizations are going to use the buffer
interface in any case.

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   Why should they be independent mechanisms ?
   What is the benefit ?  Why should something be only allowed via M-x
   customize-variable but not via M-x set-variable (and vice-versa, BTW) ?

   As a programmer, the distinction seems very faint and I have a hard time
   coming up with cases where it could make sense to prevent one use
   and allow the other.

   As a user it just makes for inconsistency where some variables can be set
   via M-x set-variable while others need M-x customize-variable.

But there is an "inconsistency" regardless of the `*' or no `*' stuff.
There are plenty of variables with :set functions for which M-x
customize-variable is going to have an effect and M-x set-variable is
not.  Having the desired effect or not having any effect whatsoever
can hardly be described as a "very faint distinction".

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Miles Bader]

On Wed, Nov 19, 2003 at 05:48:00PM -0600, Luc Teirlinck wrote:
> But there is an "inconsistency" regardless of the `*' or no `*' stuff.
> There are plenty of variables with :set functions for which M-x
> customize-variable is going to have an effect and M-x set-variable is
> not.  Having the desired effect or not having any effect whatsoever
> can hardly be described as a "very faint distinction".

This seems more like an argument for changing the way `set-variable' works
(to essentially use customize's method of setting).

I think having two sorts of `user variables' (`*' variables and `customize'
variables) is confusing and unnecessary.

-Miles
-- 
Fast, small, soon; pick any 2.

Re: doc elisp intro cross reference fixes

[Kevin Rodgers]

Miles Bader wrote:

> On Wed, Nov 19, 2003 at 05:48:00PM -0600, Luc Teirlinck wrote:
> 
>>But there is an "inconsistency" regardless of the `*' or no `*' stuff.
>>There are plenty of variables with :set functions for which M-x
>>customize-variable is going to have an effect and M-x set-variable is
>>not.  Having the desired effect or not having any effect whatsoever
>>can hardly be described as a "very faint distinction".
> 
> This seems more like an argument for changing the way `set-variable' works
> (to essentially use customize's method of setting).


I'm disappointed that's the way things appear to be headed.


> I think having two sorts of `user variables' (`*' variables and `customize'
> variables) is confusing and unnecessary.

I find more users who are confused that they can setq some variables in
their emacs (and get the desired effects), but can't M-x set-variable them.
But no one has argued that we should get rid of the special meaning of *
in defvar doc strings.

-- 
Kevin Rodgers

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> But there is an "inconsistency" regardless of the `*' or no `*' stuff.
> There are plenty of variables with :set functions for which M-x
> customize-variable is going to have an effect and M-x set-variable is
> not.  Having the desired effect or not having any effect whatsoever
> can hardly be described as a "very faint distinction".

No, indeed, it's a bug that needs to be fixed in set-variable.


        Stefan

Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   No, indeed, it's a bug that needs to be fixed in set-variable.

If this would be considered a bug, then the global variant of
set-variable would be easy to fix, by having set-variable call the
:set function.  C-u set-variable (buffer-local variant) could not be
handled this way, because :set functions are usually not intended to
handle buffer-local values.  Of course, customize-option can not
handle buffer-local values at all.  One would need a new
:set-buffer-local keyword, or similar, if one wanted set-variable to
be able to handle buffer-local values for such variables.

Sincerely,

Luc.

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>    No, indeed, it's a bug that needs to be fixed in set-variable.

> If this would be considered a bug, then the global variant of
> set-variable would be easy to fix, by having set-variable call the
> :set function.  C-u set-variable (buffer-local variant) could not be
> handled this way, because :set functions are usually not intended to
> handle buffer-local values.

That's another problem with custom in that it handles buffer-local
settings pretty poorly.  But note that for this particular case,
it's not as bad as you make it to be since there's custom-local-buffer
to take care of it.  Admittedly many setter functions don't pay attention
to it, but that's just another thing that needs to be fixed.

> Of course, customize-option can not
> handle buffer-local values at all.  One would need a new
> :set-buffer-local keyword, or similar, if one wanted set-variable to
> be able to handle buffer-local values for such variables.

No, custom-local-buffer is all you need for this particular case.


        Stefan

Re: doc elisp intro cross reference fixes

[Kevin Rodgers]

Stefan Monnier wrote:

>>I disagree.  It is a useful distinction, and programmers can take
>>advantage of it to prevent users from setting variables in a way that
>>they shouldn't (and thence submitting bug reports when they don't get
>>the desired effect).
> 
> Can you give concrete examples where the distinction makes sense ?


The example from the "Variable Definitions" node of the Emacs Lisp manual

(cited by Luc): global-font-lock-mode


>>I don't find the explanation of Variable Definitions in the Emacs Lisp
>>manual that Luc cited to be too subtle.
> 
> How many elisp programmers know about it and understand it ?


How would I know either thing about other programmers?  But ignorance of

the law is no defense.


>>set-variable and customize are independent mechanisms that are enabled
>>by a doc string convention and the custom-* symbol properties
>>respectively, and as a programmer I'd like to retain control over those
>>mechanisms.
> 
> Why should they be independent mechanisms ?
> What is the benefit ?  Why should something be only allowed via M-x
> customize-variable but not via M-x set-variable (and vice-versa, BTW) ?


They are independent because customize was introduced as a new mechanism,
instead of extending set-variable.  Whether they remain so is apparently
up for discussion.  (Would you feel comfortable removing set-variable, or
aliasing it to customize?)

Personally, I only use set-variable and avoid customize completely.  I
understand that programmers (including myself) want to provide the
customize interface to the features they provide.  But if I (as a user)
have to use customize to enable feature foo, I'd rather just do M-x
turn-on-foo-mode; and I don't want to be allowed to set-variable
foo-mode if it doesn't do the right thing.


> As a programmer, the distinction seems very faint and I have a hard time
> coming up with cases where it could make sense to prevent one use
> and allow the other.
> 
> As a user it just makes for inconsistency where some variables can be set
> via M-x set-variable while others need M-x customize-variable.


That "inconsistency" accurately reflects the difference between variables
whose values (alone) determine Emacs' behavior and those that don't (because
they interact with other things).

-- 
Kevin Rodgers

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>>> I disagree.  It is a useful distinction, and programmers can take
>>> advantage of it to prevent users from setting variables in a way that
>>> they shouldn't (and thence submitting bug reports when they don't get
>>> the desired effect).
>> Can you give concrete examples where the distinction makes sense ?
> The example from the "Variable Definitions" node of the Emacs Lisp manual
> (cited by Luc): global-font-lock-mode

As seen elsewhere, this is considered as a bug in set-variable which
should either call the setter or warn the user.  BTW, how many bug reports
did we get about such things?

>> Why should they be independent mechanisms ?
>> What is the benefit ?  Why should something be only allowed via M-x
>> customize-variable but not via M-x set-variable (and vice-versa, BTW) ?
> They are independent because customize was introduced as a new mechanism,
> instead of extending set-variable.

I asked "why *should* they be" as opposed to "why *are* they".  I know the
history behind it, of course.

> (Would you feel comfortable removing set-variable, or aliasing it to
> customize?)

set-variable and customize are two different interfaces, some people prefer
one other prefer the other, yet others use one at times and the other at
other times.
So I'd rather keep them both, but make them consistent with each other.

>> As a programmer, the distinction seems very faint and I have a hard time
>> coming up with cases where it could make sense to prevent one use
>> and allow the other.
>> As a user it just makes for inconsistency where some variables can be set
>> via M-x set-variable while others need M-x customize-variable.
> That "inconsistency" accurately reflects the difference between variables
> whose values (alone) determine Emacs' behavior and those that don't (because
> they interact with other things).

If that's the only difference, then why use a * instead of just checking
for the presence of a setter function ?
I agree that set-variable should pay attention (somehow) to customize's
setter function.


        Stefan

Re: doc elisp intro cross reference fixes

[Kai Grossjohann]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> They are independent because customize was introduced as a new mechanism,
> instead of extending set-variable.  Whether they remain so is apparently
> up for discussion.  (Would you feel comfortable removing set-variable, or
> aliasing it to customize?)

Maybe one needs to think more radical thoughts: Where is the sense in
allowing me to do (setq global-font-lock-mode t) even though it has no
effect?

Now, maybe changing setq to invoke the Custom setter would be too
weird.

But maybe it is possible to change Custom such that it doesn't need
those variables?  Then we could remove all the variables that have no
effect when set via setq, and then the set-variable problem would
(almost?) cease to exist.  Why can't Custom be told that there is a
function global-font-lock-mode that can be invoked with positive or
negative args, or not invoked at all?  It seems it should be possible
to change Custom in this way.

What do people think?

Kai

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> Maybe one needs to think more radical thoughts: Where is the sense in
> allowing me to do (setq global-font-lock-mode t) even though it has no
> effect?

Do you really mean `setq' (i.e. something outside custom or even
outside set-variable) ?

> Now, maybe changing setq to invoke the Custom setter would be too
> weird.

Especially since the toggle function called by the setter does such
a `setq'.

> But maybe it is possible to change Custom such that it doesn't need
> those variables?

Huh?  Those variables are needed for other reasons, not for custom.
There simply needs to be a place where we store the current state
of those minor modes.  For some minor modes, we can use things
like (member foo bar-hook) or somesuch, but in general we just
need a minor-mode variable.

Furthermore, AFAIK, custom already does not need the variable: if you
provide a setter and a getter that don't use the variable, it won't
use the variable.  There might be a few places in custom where
this is not quite true but it should be easy to fix.

> Then we could remove all the variables that have no
> effect when set via setq,

You also want to "remove" non-existent variable like stefan-test-1 ?


        Stefan

Re: doc elisp intro cross reference fixes

[Kai Grossjohann]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Maybe one needs to think more radical thoughts: Where is the sense in
>> allowing me to do (setq global-font-lock-mode t) even though it has no
>> effect?
>
> Do you really mean `setq' (i.e. something outside custom or even
> outside set-variable) ?

Yes.

>> But maybe it is possible to change Custom such that it doesn't need
>> those variables?
>
> Huh?  Those variables are needed for other reasons, not for custom.
> There simply needs to be a place where we store the current state
> of those minor modes.  For some minor modes, we can use things
> like (member foo bar-hook) or somesuch, but in general we just
> need a minor-mode variable.

D'oh.  I just /knew/ something had to be wrong, but I didn't know
what.  Hm.  Okay.

> Furthermore, AFAIK, custom already does not need the variable: if you
> provide a setter and a getter that don't use the variable, it won't
> use the variable.  There might be a few places in custom where
> this is not quite true but it should be easy to fix.

Well, IIUC, M-x customize-variable RET global-font-lock-mode RET is
how people frob that setting, isn't it?  And if the variable went
away, people couldn't type that anymore.  That's what I meant with
"need".

>> Then we could remove all the variables that have no
>> effect when set via setq,
>
> You also want to "remove" non-existent variable like stefan-test-1 ?

Well, err.  Hm.  How to explain...

There are some options that can be tweaked via custom by customizing a
variable.  But what actually tweaks the option is the setter function
associated with that variable.

Now one thing that could be done is to change Emacs such that the
setter function is called more often (eg, the setter function could be
called by set-variable).  Then, tweaking the option via custom and
tweaking the option another way works similarly -- by changing the
variable.

But another thing that could be done is to change Emacs such that the
variable isn't used as the custom interface anymore.  Instead of
"setting a variable" via custom, people would "turn on a hook" via
custom.  Custom could write (foo-minor-mode 1) or (foo-minor-mode -1)
into the .emacs file, depending on the setting.  This would cause the
foo-minor-mode variable to become an internal variable, not to be
changed by the user.

An effect of this would be that the foo-minor-mode variable could be
documented as storing the current state of that minor mode, and the
"Takes no effect if set via setq" warning doesn't need to be there,
anymore, since also "You can customize this variable" is gone.

Hm.  For example, M-x foo-minor-mode RET could ask the user whether to
make that setting permanent.  If the user says yes, then custom would
write its thing to custom-file.  I realize that this is most probably
not how it is going to be done, but I'm using it just as an example of
how an interface that does not use customize-variable at all is
possible.


In some sense, this is a strange idea.  After all, the current
mechanism works well.

But we already need Custom to be able to do other things than just
setting variables (and, en passant, invoking setter functions): it
would be nice if Custom could do some semantic equivalent of add-hook
or remove-hook, and it would be nice if Custom could do some semantic
equivalent of define-key.  So once we do this, we can also have Custom
do the semantic equivalent of invoking foo-minor-mode...


All of the above is just an idea.  Maybe it turns out it is better to
continue using the existing setter-functions mechanism.  Maybe you
already thought about all of this, and discovered that what I'm
suggesting doesn't work.  In this case, I apologize.

Kai

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>>> Maybe one needs to think more radical thoughts: Where is the sense in
>>> allowing me to do (setq global-font-lock-mode t) even though it has no
>>> effect?
>> 
>> Do you really mean `setq' (i.e. something outside custom or even
>> outside set-variable) ?

> Yes.

I still have trouble believe it, since in the rest of the message I get the
impression that you consider set-variable and setq as being almost
the same.  `set-variable' is much closer to customize-variable (and we
pretty much agreed in this thread that it should be made closer by paying
attention to setter functions).

>> Furthermore, AFAIK, custom already does not need the variable: if you
>> provide a setter and a getter that don't use the variable, it won't
>> use the variable.  There might be a few places in custom where
>> this is not quite true but it should be easy to fix.

> Well, IIUC, M-x customize-variable RET global-font-lock-mode RET is
> how people frob that setting, isn't it?  And if the variable went
> away, people couldn't type that anymore.  That's what I meant with
> "need".

And what I said is that even if the variable went away they still could,
because custom does not have to pay any attention to the variable: it
just calls the getter and setter and looks at properties of the symbol.

> Now one thing that could be done is to change Emacs such that the
> setter function is called more often (eg, the setter function could be
> called by set-variable).  Then, tweaking the option via custom and
> tweaking the option another way works similarly -- by changing the
> variable.

Right, that's one of things we almost agreed on in this thread (I
personally don't care whether set-variable calls the setter or not,
but it needs to pay attention to it and either call it or tell the
user that maybe he's not doing what he thinks he is).

> But another thing that could be done is to change Emacs such that the
> variable isn't used as the custom interface anymore.

It's not use as such: only the symbol is used, not the variable (i.e.
not the variable slot of the symbol).

> Instead of "setting a variable" via custom, people would "turn on a hook"
> via custom.  Custom could write (foo-minor-mode 1) or (foo-minor-mode -1)
> into the .emacs file, depending on the setting.

Custom could already do that.  I happen to think it should, but I haven't
written the code to do it (it's a bit tricky since custom needs to
be able to recognize it as a setting so it knows the state saved in the
.emacs file).


        Stefan

Re: doc elisp intro cross reference fixes

[Kai Grossjohann]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> Furthermore, AFAIK, custom already does not need the variable: if you
>>> provide a setter and a getter that don't use the variable, it won't
>>> use the variable.  There might be a few places in custom where
>>> this is not quite true but it should be easy to fix.
>
>> Well, IIUC, M-x customize-variable RET global-font-lock-mode RET is
>> how people frob that setting, isn't it?  And if the variable went
>> away, people couldn't type that anymore.  That's what I meant with
>> "need".
>
> And what I said is that even if the variable went away they still could,
> because custom does not have to pay any attention to the variable: it
> just calls the getter and setter and looks at properties of the symbol.

Sorry, I still said something misleading.  I didn't know that Custom
only looked at the symbol.

>> Now one thing that could be done is to change Emacs such that the
>> setter function is called more often (eg, the setter function could be
>> called by set-variable).  Then, tweaking the option via custom and
>> tweaking the option another way works similarly -- by changing the
>> variable.
>
> Right, that's one of things we almost agreed on in this thread (I
> personally don't care whether set-variable calls the setter or not,
> but it needs to pay attention to it and either call it or tell the
> user that maybe he's not doing what he thinks he is).

Yes, that's one way to do it.  Is it the only one?

>> But another thing that could be done is to change Emacs such that the
>> variable isn't used as the custom interface anymore.
>
> It's not use as such: only the symbol is used, not the variable (i.e.
> not the variable slot of the symbol).

But to the user, it looks like setting a variable:

M-x customize-variable RET scroll-step RET
M-x customize-variable RET global-font-lock-mode RET

The former is just a pretty interface to setting a variable, the
latter is a pretty interface to the global-font-lock-mode function.
The only way for a user to see that they are different is from the
name of the variable.

Maybe it's my view at things.  For me, Custom is a pretty interface
for things people do in their .emacs files.  And setq is one of them,
whereas add-hook and define-key are others.  It looks a lot like
customize-variable is the pretty interface to setq, whereas pretty
interfaces to add-hook and define-key are lacking.  And once you add
pretty interfaces to add-hook and define-key, you can also add a
pretty interface to turning on/off modes.

I even asked for being able to add comments to custom settings, since
";;" is also often used in my .emacs file ;-)


It's quite possible that this is a bad way at looking at it.  What's
the way you look at it?


>> Instead of "setting a variable" via custom, people would "turn on a hook"

Eek.  I meant "turn on a mode", not "turn on a hook".

>> via custom.  Custom could write (foo-minor-mode 1) or (foo-minor-mode -1)
>> into the .emacs file, depending on the setting.
>
> Custom could already do that.  I happen to think it should, but I haven't
> written the code to do it (it's a bit tricky since custom needs to
> be able to recognize it as a setting so it knows the state saved in the
> .emacs file).

Cool.

Kai

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> Maybe it's my view at things.  For me, Custom is a pretty interface
> for things people do in their .emacs files.  And setq is one of them,
> whereas add-hook and define-key are others.  It looks a lot like

100% agreement.

Being able to set values on a per-mode basis (which translates into adding
stuff to a hook) is sorely lacking.

Custom could already recognize minor modes based on the setter function
(for instance) or by minor modification to define-minor-mode (one of the
reasons why I find it important to use such macros for defining minor modes
and major modes).


        Stefan

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    Custom could already recognize minor modes based on the setter function
    (for instance) or by minor modification to define-minor-mode (one of the
    reasons why I find it important to use such macros for defining minor modes
    and major modes).

I think that would be a very useful feature.

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    Maybe one needs to think more radical thoughts: Where is the sense in
    allowing me to do (setq global-font-lock-mode t) even though it has no
    effect?

    Now, maybe changing setq to invoke the Custom setter would be too
    weird.

    But maybe it is possible to change Custom such that it doesn't need
    those variables?

Setting the variable with setq may not be useful, but looking at its
value is useful.  It makes no sense to eliminate the variable.

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    What is the benefit ?  Why should something be only allowed via M-x
    customize-variable but not via M-x set-variable (and vice-versa, BTW) ?

Maybe it would be ok to use customizability as the criterion
for user-variable-p.  However, I am not sure it would be an improvement
over the current way of handling things.

Re: doc elisp intro cross reference fixes

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     What is the benefit ?  Why should something be only allowed via M-x
>     customize-variable but not via M-x set-variable (and vice-versa, BTW) ?
> 
> Maybe it would be ok to use customizability as the criterion
> for user-variable-p.  However, I am not sure it would be an improvement
> over the current way of handling things.

Doing so would at least get rid of the current confusing distinction
between these two type of `user variables'.  It would also make using
`customization only' variables simpler for those people that don't like
the normal heavy-weight customize user interface.  Are there really
disadvantages great enough to offset those advantages?

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>     What is the benefit ?  Why should something be only allowed via M-x
>     customize-variable but not via M-x set-variable (and vice-versa, BTW) ?

> Maybe it would be ok to use customizability as the criterion
> for user-variable-p.  However, I am not sure it would be an improvement
> over the current way of handling things.

AFAIK, the current way of doing things is already to use customizability as
a criterion for user-variable-p, making * only meaningful for defvar but
not for defcustom.  Are you saying that you want to remove even the
support for * in defvar (instead relying exclusively on defcustom)?
That would be fine by me, but it's more than I'm trying to do here
(which is to bring the doc in line with the code).


        Stefan

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    > Maybe it would be ok to use customizability as the criterion
    > for user-variable-p.  However, I am not sure it would be an improvement
    > over the current way of handling things.

    AFAIK, the current way of doing things is already to use customizability as
    a criterion for user-variable-p, making * only meaningful for defvar but
    not for defcustom.  Are you saying that you want to remove even the
    support for * in defvar (instead relying exclusively on defcustom)?

I didn't say I *want* to make this change.  Rather, I expressed
doubts about it.

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    Anyway my point is that the difference between defcustom with and without
    a * is in practice absent and in theory much too subtle and debatable to
    justify its existence (after all, who knows whether users will want to set
    something interactively or only at startup).

Shouldn't set-variable distinguish, at least for completion purposes?

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>     Anyway my point is that the difference between defcustom with and
>     without a * is in practice absent and in theory much too subtle and
>     debatable to justify its existence (after all, who knows whether users
>     will want to set something interactively or only at startup).

> Shouldn't set-variable distinguish, at least for completion purposes?

Why should it ?

Programmers forget the * all the time, so people complained about some vars
being settable via customize-variable but not via set-variable, and it
was fixed so the * is irrelevant for `defcustom'.  I think that's a good
thing and I'd like to bring the doc in line with the code.


        Stefan

Re: doc elisp intro cross reference fixes

[Kevin Rodgers]

Stefan Monnier wrote:

> Programmers forget the * all the time, so people complained about some vars
> being settable via customize-variable but not via set-variable, and it
> was fixed so the * is irrelevant for `defcustom'.  I think that's a good
> thing and I'd like to bring the doc in line with the code.

I think we should educate programmers to fix their broken code, not change

Emacs (which wasn't broken).

-- 
Kevin Rodgers

Re: doc elisp intro cross reference fixes

[Stefan Monnier]

>> Programmers forget the * all the time, so people complained about some vars
>> being settable via customize-variable but not via set-variable, and it
>> was fixed so the * is irrelevant for `defcustom'.  I think that's a good
>> thing and I'd like to bring the doc in line with the code.

> I think we should educate programmers to fix their broken code, not change
> Emacs (which wasn't broken).

That's effort.  If the only benefit is to prevent some users from using
set-variable because the programmer thinks it's too cumbersome, I find
this effort is plainly wasted.


        Stefan

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Could someone explain to me the subtle differences between:
> - defvar with a * in the docstring.
> - defcustom with no * in the docstring.
> - defcustom with a * in the docstring.

The way I have treated them are:

If the variable has a value that the user is likely to want to save
between sessions, use defcustom.

If the variable has a value that the user is likely to want to change
multiple times in a single session during normal use, use *.

Something like "foo-mime-type-alist" should be defcustom without *, as
it is something pretty complex you'd want to define once, and then use
for ever after.  You'd change it only to get it right, not as part of
normal use.  But something like case-fold-search would be a
prototypical example of an option the user may want to change several
times in a session.

On the other hand, it should also be clear that

1) programmers don't understand the distinction

I spend a lot of time fixing removing or adding "*" from Gnus options,
most other developers seemed to either add it always or never.  Even
to the degree of adding or removing * from old code so everything was
the same.

2) programmers can't judge when an option is something users would
   want to change as part of normal use

3) having too many choices for set-variable is much less of a
   problem than having too few.
   
so I think it would be best to retire the "*" convention entirely.
Actually enforcing it would be too much work for too little gain.

Re: doc elisp intro cross reference fixes

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> On the other hand, it should also be clear that
>
> 1) programmers don't understand the distinction
>
> I spend a lot of time fixing removing or adding "*" from Gnus options,
> most other developers seemed to either add it always or never.  Even
> to the degree of adding or removing * from old code so everything was
> the same.
>
> 2) programmers can't judge when an option is something users would
>    want to change as part of normal use
>
> 3) having too many choices for set-variable is much less of a
>    problem than having too few.

To be fair to us programmers that doesn't understand the distinction:
the elisp manual should probably be attributed a large part of the
blame, because it is not very clear on what programmers should do.
Assuming programmers will intuitively know how to use "*" is asking
for too much, I think.  If the manual was clear on when to use "*"
with both defvar and defcustom, at least programmers would be able to
learn the distinction.

> so I think it would be best to retire the "*" convention entirely.
> Actually enforcing it would be too much work for too little gain.

FWIW, I agree.

Re: doc elisp intro cross reference fixes

[Juri Linkov]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> On the other hand, it should also be clear that
>
> 1) programmers don't understand the distinction
>
> I spend a lot of time fixing removing or adding "*" from Gnus options,
> most other developers seemed to either add it always or never.  Even
> to the degree of adding or removing * from old code so everything was
> the same.
>
> 2) programmers can't judge when an option is something users would
>    want to change as part of normal use

I just grepped the emacs/lisp/ file tree and results clearly
demonstrate that programmers use * quite randomly.  There are even
24 constants (defconst) and 33 faces (defface) with * in their docstrings!
And most defvars with * undoubtedly should be changed to defcustom.
All this indicate that * for its current purpose is a useless feature.

I want to note also that currently there are many defvar variables
that are intended for customization but have no * in their docstrings.
Their values are either too complicated or by some other reasons they
are not suited for interactive modification and are intended for change
from Lisp programs (mostly in .emacs).  There should be some way
to distinguish them from internal variables (whose only purpose is
to communicate global values between functions and some other purely
internal purpose).  I suppose that there is such implicit convention
already exists that internal variables should have no docstrings.
Is it true?

-- 
http://www.jurta.org/emacs/

Re: doc elisp intro cross reference fixes

[Per Abrahamsen]

Juri Linkov <juri@jurta.org> writes:

> I suppose that there is such implicit convention already exists that
> internal variables should have no docstrings.  Is it true?

It used to be true back when doc-strings were dumped into the
executable and memory was scarce.  

But I believe doc-strings for internal variables and functions are
considered acceptable these days.

There are a couple of naming conventions sporadically used by
functions, like adding "-1" to the name of helper functions, or adding
"internal" to the name of the function.

Re: doc elisp intro cross reference fixes

[Richard Stallman]

    It used to be true back when doc-strings were dumped into the
    executable and memory was scarce.  

Exactly.  We wrote comments instead of doc strings for internal
functions and variables.

    But I believe doc-strings for internal variables and functions are
    considered acceptable these days.

That's correct.  Nowadays, we may as well make these comments into doc
strings.  They are easier to find that way, and it does no harm.

Re: doc elisp intro cross reference fixes

[Peter S Galbraith]

Juri Linkov <juri@jurta.org> wrote:

>                     I suppose that there is such implicit convention
> already exists that internal variables should have no docstrings.
> Is it true?

`M-x checkdoc' says they should have doc strings.

Re: doc elisp intro cross reference fixes

[Kevin Ryde]

Juri Linkov <juri@jurta.org> writes:
>
> BTW, does such an Emacs package exist that finds broken links in Info
> documents like HTML link checkers do?

info-xref.el :)

Re: doc elisp intro cross reference fixes

[Juri Linkov]

Kevin Ryde <user42@zip.com.au> writes:
> Juri Linkov <juri@jurta.org> writes:
>> BTW, does such an Emacs package exist that finds broken links in Info
>> documents like HTML link checkers do?
>
> info-xref.el :)

Oops...  This is something new.  I missed it, because it was not announced
in the NEWS file.  Now I see how you found those broken links.
Did you check all other Info files?

-- 
http://www.jurta.org/emacs/

Re: doc elisp intro cross reference fixes

[Kevin Ryde]

Juri Linkov <juri@jurta.org> writes:
>
> Did you check all other Info files?

Yes, see other message for a link in viper.texi needing to be updated.

dired alignment

[Karl Eichwalder]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

Since several days I observe an dired alignment failure when trying to
copy a file pressing `C'.  Point sits on `.emacs.test', press

    C .emacs.test2 RET

and all spaces are collapsed to just-one-space (cf. attachment).  Press
`g' and proper re-alignemnt will happen.


[-- Attachment #2: e.png --]
[-- Type: image/png, Size: 8324 bytes --]

[-- Attachment #3: Type: text/plain, Size: 214 bytes --]



-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)

[-- Attachment #4: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: dired alignment

[Andreas Schwab]

Karl Eichwalder <ke@gnu.franken.de> writes:

> Since several days I observe an dired alignment failure when trying to
> copy a file pressing `C'.  Point sits on `.emacs.test', press
>
>     C .emacs.test2 RET
>
> and all spaces are collapsed to just-one-space (cf. attachment).  Press
> `g' and proper re-alignemnt will happen.

That's a side effect of recent changes in coreutils.  Columns in the
output of ls are now expanded only to the extend needed to keep the whole
output aligned, so when listing only one file the whitespace between
columns will be minimal.  BSD ls apparently had this feature already for a
longer time, at least MacOS 10.1 already does that.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: dired alignment

[Richard Stallman]

    >     C .emacs.test2 RET
    >
    > and all spaces are collapsed to just-one-space (cf. attachment).  Press
    > `g' and proper re-alignemnt will happen.

    That's a side effect of recent changes in coreutils.  Columns in the
    output of ls are now expanded only to the extend needed to keep the whole
    output aligned, so when listing only one file the whitespace between
    columns will be minimal.

This is not good.  Should I ask the coreutils developer to change this?
Should Emacs try to align the indentation as it comes in?

Re: dired alignment

[Stefan Monnier]

>     That's a side effect of recent changes in coreutils.  Columns in the
>     output of ls are now expanded only to the extend needed to keep the whole
>     output aligned, so when listing only one file the whitespace between
>     columns will be minimal.

> This is not good.  Should I ask the coreutils developer to change this?

I doubt you'll be able to convince him.  It's a good feature: no fixed
predefined column sizes, it's all automatically adjusted.

> Should Emacs try to align the indentation as it comes in?

Looks that way, :-(


        Stefan

Re: dired alignment

[Richard Stallman]

    > Should Emacs try to align the indentation as it comes in?

    Looks that way, :-(

This means Emacs has to be able to distinguish all the columns.
That may be difficult for the user and group if they contain
spaces.  I guess we have to simply abandon that case.

Can someone work on this?

Re: dired alignment

[Peter Whaite]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >     That's a side effect of recent changes in coreutils.  Columns in the
> >     output of ls are now expanded only to the extend needed to keep the whole
> >     output aligned, so when listing only one file the whitespace between
> >     columns will be minimal.
> 
> > This is not good.  Should I ask the coreutils developer to change this?
> 
> I doubt you'll be able to convince him.  It's a good feature: no fixed
> predefined column sizes, it's all automatically adjusted.

Shouldn't the --dired switch do the right thing?

-- 
Peter Whaite (http://whaite.ca)

Re: dired alignment

[Richard Stallman]

    > I doubt you'll be able to convince him.  It's a good feature: no fixed
    > predefined column sizes, it's all automatically adjusted.

    Shouldn't the --dired switch do the right thing?

Do you mean, using --dired should force the old-style alignment?
That might be a good partial solution.

However, we will still have problems with non-GNU versions of ls,
so we might want to make Dired fix the alignment when it doesn't
use --dired.

Re: dired alignment

[Peter Whaite]

Richard Stallman <rms@gnu.org> wrote:
>
> Do you mean, using --dired should force the old-style alignment?
> That might be a good partial solution.

It was more a coreutils than an emacs comment.  It looks like the `ls`
alignment changes were intended to make life easier for interactive
users on a terminal console.  However those changes shouldn't have
affected --dired output which is in effect a protocol to communicate
with emacs dired mode.

> However, we will still have problems with non-GNU versions of ls,
> so we might want to make Dired fix the alignment when it doesn't
> use --dired.

That's another problem, though perhaps dired.el should always work with
'ls -l --dired' output, and that for non-GNU versions of ls, a layer of
elisp filters be added to convert to produce the dired output.

I hasten to add that I know very little about how dired actually works.

-- 
Peter Whaite (http://whaite.ca)

Re: dired alignment

[Stefan Monnier]

>> Do you mean, using --dired should force the old-style alignment?
>> That might be a good partial solution.

> It was more a coreutils than an emacs comment.  It looks like the `ls`
> alignment changes were intended to make life easier for interactive
> users on a terminal console.  However those changes shouldn't have
> affected --dired output which is in effect a protocol to communicate
> with emacs dired mode.

>> However, we will still have problems with non-GNU versions of ls,
>> so we might want to make Dired fix the alignment when it doesn't
>> use --dired.

Note that the problem is more general than that.  If a group has a very
long name or a file is very large, alignment is lost in the output of old
GNU ls whereas it is preserved in the new.
I.e. the new alignment in GNU ls breaks alignment betwen different
invocations of `ls' but fixes alignment within a single invocation of `ls'.
And you can't have it both ways.

> That's another problem, though perhaps dired.el should always work with
> 'ls -l --dired' output, and that for non-GNU versions of ls, a layer of
> elisp filters be added to convert to produce the dired output.

IIRC, the --dired flag only indicates whre the file names start/end,
which doesn't help much for alignment of other fields.


        Stefan

Re: dired alignment

[Richard Stallman]

    Note that the problem is more general than that.  If a group has a very
    long name or a file is very large, alignment is lost in the output of old
    GNU ls whereas it is preserved in the new.
    I.e. the new alignment in GNU ls breaks alignment betwen different
    invocations of `ls' but fixes alignment within a single invocation of `ls'.
    And you can't have it both ways.

That's correct.  What we want in Dired is the old behavior:
align ordinary lines the same way, and treat peculiar lines
specially.

Re: dired alignment

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     Note that the problem is more general than that.  If a group has a very
>     long name or a file is very large, alignment is lost in the output of old
>     GNU ls whereas it is preserved in the new.
>     I.e. the new alignment in GNU ls breaks alignment betwen different
>     invocations of `ls' but fixes alignment within a single invocation of `ls'.
>     And you can't have it both ways.
>
> That's correct.  What we want in Dired is the old behavior:
> align ordinary lines the same way, and treat peculiar lines
> specially.

IMHO it would be a step backwards if Dired would force unaligned output.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: dired alignment

[Richard Stallman]

    IMHO it would be a step backwards if Dired would force unaligned output.

What does it mean to "force unaligned output"?
I can't relate that to any of the options
we are discussing.

Re: dired alignment

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     IMHO it would be a step backwards if Dired would force unaligned output.
>
> What does it mean to "force unaligned output"?
> I can't relate that to any of the options
> we are discussing.

With "force unaligned output" I meant the old way of using fixed width
columns.  Sorry for the sloppy wording.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: dired alignment

[Miles Bader]

On Thu, May 13, 2004 at 11:46:01AM -0400, Richard Stallman wrote:
> That's correct.  What we want in Dired is the old behavior:
> align ordinary lines the same way, and treat peculiar lines
> specially.

Actually, if it could be handled correctly, I'd rather like the new behavior
in dired too (I use direct much more often than I use plain ls) -- it's
annoying when columns take up much more room than they actually need.

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: dired alignment

[Richard Stallman]

    Actually, if it could be handled correctly, I'd rather like the new behavior
    in dired too (I use direct much more often than I use plain ls) -- it's
    annoying when columns take up much more room than they actually need.

To do this would require dired to realign all the lines whenever one
line changes.  This would be a nuisance in a number of ways.  One
file with a long group name could make all the file names cause
line continuation.

Re: dired alignment

[Miles Bader]

On Fri, May 14, 2004 at 05:02:13PM -0400, Richard Stallman wrote:
>     Actually, if it could be handled correctly, I'd rather like the new
>     behavior in dired too (I use direct much more often than I use plain
>     ls) -- it's annoying when columns take up much more room than they
>     actually need.
> 
> To do this would require dired to realign all the lines whenever one
> line changes.

I think this could eaily be handled by (1) adding a small amount of
hysteresis (e.g., rounding up widths to a multiple of 4), and (2) just
redrawing everything if the resulting width changed.  The only commonly
changing piece of info is file size, which would be largely accommodated by
(1) -- and even that's only necessary when the changed file happens to be
significantly different in size than all the other files, which on average
probably won't be the case.

> This would be a nuisance in a number of ways.  One file with a long group
> name could make all the file names cause line continuation.

There could be an upper limit.  I find that pretty much all the files in a
given directory usually have the same user/group anyway, so I'm not sure it
makes much difference in practice.

Anyway, I'm just pontificating; I think such a display would be nicer, but of
course any such new feature requires work, and I'm not volunteering to do
it... :-)

-Miles
-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: dired alignment

[Edward O'Connor]

>> That's a side effect of recent changes in coreutils. Columns in the
>> output of ls are now expanded only to the extend needed to keep the
>> whole output aligned, so when listing only one file the whitespace
>> between columns will be minimal.

Note that FreeBSD's ls has had this behavior for a long time. Enhancing
Dired to better support GNU ls will have the added benefit of improving
Dired's behavior on other systems as well.


-- 
Edward O'Connor
ted@oconnor.cx

Ense petit placidam sub libertate quietem.

Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS)

[Peter Whaite]

Some time ago there was a thread on division being inconsistent when
floats were involved.  I dont know what the outcome of that discussion
was, but it did occur to me that the simplest fix would be to multiply
the divisors before doing the division.  Here is code for that
(src/data.c)...

DEFUN ("/", Fquo, Squo, 2, MANY, 0,
       doc: /* Return first argument divided by all the remaining arguments.
The arguments must be numbers or markers.
usage: (/ DIVIDEND DIVISOR &rest DIVISORS)  */)
     (nargs, args)
     int nargs;
     Lisp_Object *args;
{
  if (nargs == 2) {
    return arith_driver (Adiv, nargs, args);
  }
  else {
    Lisp_Object divArgs[2];
    divArgs[0] = args[0];
    divArgs[1] = arith_driver (Amult, nargs-1, args+1);
    return arith_driver (Adiv, 2, divArgs);
  }
}

I've left nargs==2 as a special case for efficiency, because it wont
change the existing behavior for 2 arguments, and because 2 arguments is
by far the most common, and perhaps only, usage I see in the cvs *.el
files.

-- 
Peter Whaite (http://whaite.ca)

Re: Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS)

[Miles Bader]

On Tue, May 04, 2004 at 06:27:11PM -0400, Peter Whaite wrote:
> Some time ago there was a thread on division being inconsistent when
> floats were involved.  I dont know what the outcome of that discussion
> was, but it did occur to me that the simplest fix would be to multiply
> the divisors before doing the division.

That might result in overflow where there wasn't any before, especially when
all the args are fixnums.

E.g., currently:

   (/ 200000000 100000000 4)   =>  0

But your change would seem to make it equivalent to:

   (/ 200000000 (* 100000000 4)) => -1

Given that emacs already has a very restricted integer range, this is an area
where we should be very careful.

-Miles
-- 
97% of everything is grunge

Re: Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS)

[Peter Whaite]

Miles Bader <miles@gnu.org> wrote:

> On Tue, May 04, 2004 at 06:27:11PM -0400, Peter Whaite wrote:
> > Some time ago there was a thread on division being inconsistent when
> > floats were involved.  I dont know what the outcome of that discussion
> > was, but it did occur to me that the simplest fix would be to multiply
> > the divisors before doing the division.
> 
> That might result in overflow where there wasn't any before, especially when
> all the args are fixnums.

Oh you're right and it isn't the first time I've fallen for that one.  I
was fixated on floats.

-- 
Peter Whaite (http://whaite.ca)

Re: Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS)

[David Kastrup]

Peter Whaite <emacs@whaite.ca> writes:

> Miles Bader <miles@gnu.org> wrote:
> 
> > On Tue, May 04, 2004 at 06:27:11PM -0400, Peter Whaite wrote:
> > > Some time ago there was a thread on division being inconsistent when
> > > floats were involved.  I dont know what the outcome of that discussion
> > > was, but it did occur to me that the simplest fix would be to multiply
> > > the divisors before doing the division.
> > 
> > That might result in overflow where there wasn't any before, especially when
> > all the args are fixnums.
> 
> Oh you're right and it isn't the first time I've fallen for that one.  I
> was fixated on floats.

Floats also overflow, merely later.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Mode-line customization.

[Matt Hodges]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

This patch might appeal to people migrating from XEmacs, who want to
colourise their mode lines. It might be nice to have these faces
available, even if they're not visibly different from mode-line, by
default.

Matt


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch adding faces to modeline. --]
[-- Type: text/x-patch, Size: 2634 bytes --]

cvs server: Diffing lisp
Index: lisp/bindings.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.130
diff -u -r1.130 bindings.el
--- lisp/bindings.el	1 May 2004 03:50:24 -0000	1.130
+++ lisp/bindings.el	4 May 2004 22:36:46 -0000
@@ -303,10 +303,12 @@
     (list
      (propertize "%[(" 'help-echo help-echo)
      `(:propertize ("" mode-name)
+                   face mode-line-major-mode
 		   help-echo "mouse-2: help for current major mode"
 		   local-map ,mode-line-major-mode-keymap)
      '("" mode-line-process)
      `(:propertize ("" minor-mode-alist)
+                   face mode-line-minor-mode
 		   help-echo "mouse-2: help for minor modes, mouse-3: minor mode menu"
 		   local-map ,mode-line-minor-mode-keymap)
      (propertize "%n" 'help-echo "mouse-2: widen"
Index: lisp/faces.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/faces.el,v
retrieving revision 1.283
diff -u -r1.283 faces.el
--- lisp/faces.el	26 Mar 2004 15:12:33 -0000	1.283
+++ lisp/faces.el	4 May 2004 22:36:46 -0000
@@ -1828,9 +1828,31 @@
   :group 'modeline
   :group 'basic-faces)
 
+(defface mode-line-major-mode
+  '((((type x w32 mac) (class color))
+     :foreground "red")
+    (t
+     :background "red"))
+  "Face used to indicate `major-mode' in the mode line."
+  :version "21.4"
+  :group 'modeline
+  :group 'basic-faces)
+
+(defface mode-line-minor-mode
+  '((((type x w32 mac) (class color))
+     :foreground "green4")
+    (t
+     :background "green"))
+  "Face used to indicate minor modes in the mode line."
+  :version "21.4"
+  :group 'modeline
+  :group 'basic-faces)
+
 ;; Make `modeline' an alias for `mode-line', for compatibility.
 (put 'modeline 'face-alias 'mode-line)
 (put 'modeline-inactive 'face-alias 'mode-line-inactive)
+(put 'modeline-major-mode 'face-alias 'mode-line-major-mode)
+(put 'modeline-minor-mode 'face-alias 'mode-line-minor-mode)
 
 (defface header-line
   '((t
cvs server: Diffing lisp/calc
cvs server: Diffing lisp/calendar
cvs server: Diffing lisp/emacs-lisp
cvs server: Diffing lisp/emulation
cvs server: Diffing lisp/eshell
cvs server: Diffing lisp/gnus
cvs server: Diffing lisp/international
cvs server: Diffing lisp/language
cvs server: Diffing lisp/mail
cvs server: Diffing lisp/mh-e
cvs server: Diffing lisp/net
cvs server: Diffing lisp/obsolete
cvs server: Diffing lisp/play
cvs server: Diffing lisp/progmodes
cvs server: Diffing lisp/term
cvs server: Diffing lisp/textmodes
cvs server: Diffing lisp/toolbar
cvs server: Diffing lisp/url

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Mode-line customization.

[Chris Green]

Matt Hodges <matt@tc.bham.ac.uk> writes:

> This patch might appeal to people migrating from XEmacs, who want to
> colourise their mode lines. It might be nice to have these faces
> available, even if they're not visibly different from mode-line, by
> default.

Indeed it does appeal.

One of the things I've found I miss the most from XEmacs deals with
VC.  When you modify a version controlled file in XEmacs, the
background of the CVS version becomes highlighted.  In Emacs, it goes
from CVS-1.21 => CVS:1.21 which isn't obvious until you read the
docstring for vc-default-mode-line-string. 

I was disappointed that I couldn't customize to get that behavior
back.
-- 
Chris Green <cmg@dok.org>
Fame may be fleeting but obscurity is forever.

Re: Mode-line customization.

[Juanma Barranquero]

On Wed, 05 May 2004 11:04:16 -0400, Chris Green <cmg@dok.org> wrote:

> When you modify a version controlled file in XEmacs, the
> background of the CVS version becomes highlighted.  In Emacs, it goes
> from CVS-1.21 => CVS:1.21 which isn't obvious until you read the
> docstring for vc-default-mode-line-string. 
> 
> I was disappointed that I couldn't customize to get that behavior
> back.

You can't M-x customize it, but certainly you can customize it:

(setcdr (nth 7 mode-line-format)
               '((:eval (let ((v (concat vc-mode " ")))
                          (if (string-match ":" v)
                           (propertize v 'face '(:background "red"))
                        (propertize v 'face '(:background "brown")))))))

etc.

Though I fully agree that having mode-line-major-mode,
mode-line-minor-mode and other mode-line specific faces would be great.

                                                           /L/e/k/t/u

Re: Mode-line customization.

[Richard Stallman]

    One of the things I've found I miss the most from XEmacs deals with
    VC.  When you modify a version controlled file in XEmacs, the
    background of the CVS version becomes highlighted.  In Emacs, it goes
    from CVS-1.21 => CVS:1.21 which isn't obvious until you read the
    docstring for vc-default-mode-line-string. 

Let's just put in that feature.  Why not?

Re: Mode-line customization.

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> When you modify a version controlled file in XEmacs, the background of
> the CVS version becomes highlighted.  In Emacs, it goes from CVS-1.21
> => CVS:1.21 which isn't obvious
> 
> Let's just put in that feature.  Why not?

Maybe it would be even more clear if we used the _same_ background face
to highlight the normal buffer-modified indicator the mode-line.  That
way users would get used to that color meaning `modified.'

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: Mode-line customization.

[David Kastrup]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Richard Stallman <rms@gnu.org> writes:
> > When you modify a version controlled file in XEmacs, the background of
> > the CVS version becomes highlighted.  In Emacs, it goes from CVS-1.21
> > => CVS:1.21 which isn't obvious
> > 
> > Let's just put in that feature.  Why not?
> 
> Maybe it would be even more clear if we used the _same_ background face
> to highlight the normal buffer-modified indicator the mode-line.  That
> way users would get used to that color meaning `modified.'

Then we should probably change the display CVS:1.21 to CVS*1.21
also?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Mode-line customization.

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> > Maybe it would be even more clear if we used the _same_ background face
> > to highlight the normal buffer-modified indicator the mode-line.  That
> > way users would get used to that color meaning `modified.'
> 
> Then we should probably change the display CVS:1.21 to CVS*1.21
> also?

Personally I think CVS*1.21 is a bit too ugly to be worth it.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Mode-line customization.

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> 
> Personally I think CVS*1.21 is a bit too ugly to be worth it.

Ugly, but for that reason also more legible.  

Actually, I never noticed the difference between CVS-1.21 and CVS:1.21,
but I'm pretty sure I would have noticed CVS*1.21.

An alternative would be CVS-1.21*  


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Mode-line customization.

[Miles Bader]

On Thu, May 06, 2004 at 01:59:16PM +0200, Kim F. Storm wrote:
> > Personally I think CVS*1.21 is a bit too ugly to be worth it.
> 
> Ugly, but for that reason also more legible.  

Actually my concern is that visually, it's _less_ legible -- you really want
something that acts a bit like whitespace surrounding the numbers, and both
`-' and `:' serve that purpose -- but `*' is a much more dominant character.

-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

Re: Mode-line customization.

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> On Thu, May 06, 2004 at 01:59:16PM +0200, Kim F. Storm wrote:
> > > Personally I think CVS*1.21 is a bit too ugly to be worth it.
> > 
> > Ugly, but for that reason also more legible.  
> 
> Actually my concern is that visually, it's _less_ legible -- you
> really want something that acts a bit like whitespace surrounding
> the numbers, and both `-' and `:' serve that purpose -- but `*' is a
> much more dominant character.

Which is an advantage.  It took me several weeks to months to notice
and figure out the subtle difference between CVS-1.21 and CVS:1.21.
It is something that escapes the casual user completely.  CVS*1.21 not
only uses the same meme as the buffer modification flag, it is also
much more apparent.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Mode-line customization.

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Which is an advantage.  It took me several weeks to months to notice
> and figure out the subtle difference between CVS-1.21 and CVS:1.21.
> It is something that escapes the casual user completely.  CVS*1.21 not
> only uses the same meme as the buffer modification flag, it is also
> much more apparent.

The problem is that it makes it harder to read the version number,
which is important, and just generally, stuffing it in there seems bit
... kludgey.  It may also be less nice with other version-numbering
schemes, e.g., in arch the modeline-version looks something like:
`Arch-468[devo--0]'.

If this is actually important (I'm not convinced really), I'd much
prefer something like a variation on what Kim suggestion, e.g.:

   **CVS:1.21

(changing the - to : as well, to clue in traditionalists).

Or, theoretically with arch:  **Arch-468[devo--0]

Putting it _before_ the VC name make it even easier to see than an
embedded `*' or one which follows, and interfere less with the actual
contents of the VC version string.  Doubling it makes it even _more_
obvious, and as you pointed out, reinforces the analogy with the
buffer-modified indicator.

-Miles
-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: Mode-line customization.

[David Kastrup]

Miles Bader <miles@lsi.nec.co.jp> writes:

> David Kastrup <dak@gnu.org> writes:
> > Which is an advantage.  It took me several weeks to months to notice
> > and figure out the subtle difference between CVS-1.21 and CVS:1.21.
> > It is something that escapes the casual user completely.  CVS*1.21 not
> > only uses the same meme as the buffer modification flag, it is also
> > much more apparent.
> 
> The problem is that it makes it harder to read the version number,

Not really.

> which is important, and just generally, stuffing it in there seems
> bit ... kludgey.

The original behavior was just as kludgy.  My proposal apparently
triggers your "kludginess" sensor simply because it is visible.  That
means that the original was ok with you because it completely escaped
notice.  It was sort of an insider joke.

An indicator that is not noticeable is useless.

> It may also be less nice with other version-numbering schemes, e.g.,
> in arch the modeline-version looks something like:
> `Arch-468[devo--0]'.

So where is the problem?  We still have an initial dash that is not
part of the version itself.

> If this is actually important (I'm not convinced really), I'd much
> prefer something like a variation on what Kim suggestion, e.g.:
> 
>    **CVS:1.21
> 
> (changing the - to : as well, to clue in traditionalists).

It has the disadvantage that it takes up two additional characters in
a modeline that is already too short for many purposes.  That most
certainly was the reason for the original kludge.

> Putting it _before_ the VC name make it even easier to see than an
> embedded `*' or one which follows, and interfere less with the actual
> contents of the VC version string.  Doubling it makes it even _more_
> obvious, and as you pointed out, reinforces the analogy with the
> buffer-modified indicator.

Too much so, actually: it makes it appear the _same_, so people will
get confused into thinking the buffer has been modified.  If the * is
part of the CVS string, it at least becomes apparent that it has
something to do with CVS.

I am not saying that CVS*1.18 might be the hottest thing on Earth,
but I can't see it as bad as you seem to.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Mode-line customization.

[Kevin Rodgers]

David Kastrup wrote:
 > Miles Bader <miles@lsi.nec.co.jp> writes:
 >>David Kastrup <dak@gnu.org> writes:
 >>>Which is an advantage.  It took me several weeks to months to notice
 >>>and figure out the subtle difference between CVS-1.21 and CVS:1.21.
 >>>It is something that escapes the casual user completely.  CVS*1.21 not
 >>>only uses the same meme as the buffer modification flag, it is also
 >>>much more apparent.
 >>
 >>The problem is that it makes it harder to read the version number,
 >
 > Not really.
...
 > I am not saying that CVS*1.18 might be the hottest thing on Earth,
 > but I can't see it as bad as you seem to.

vc.el:
(defvar vc-mode-line-unlocked ?-)
(defvar vc-mode-line-locked ?*)

~miles/.emacs:
(setq vc-mode-line-locked ?:)

Or vice versa :-)

-- 
Kevin Rodgers

Re: Mode-line customization.

[Stefan Monnier]

> (defvar vc-mode-line-unlocked ?-)
> (defvar vc-mode-line-locked ?*)

Wrong names.  Better use "modified" than "unlocked".
CVS, SVN, Arch, MetaCVS are supported by VC but do not use locking.
Only RCS and SCCS use locking and even the VC support in RCS tries to
support a non-locking mode.  Nowadays locking is the exception rather than
the rule, at least in the free software world.


        Stefan

Re: Mode-line customization.

[Richard Stallman]

    The problem is that it makes it harder to read the version number,
    which is important.

We can put a space after the *.  That would make it very easy
to read the version number.  Or we could insert the * before
the dash.

    If this is actually important (I'm not convinced really), I'd much
    prefer something like a variation on what Kim suggestion, e.g.:

       **CVS:1.21

That might be good.

Re: Mode-line customization.

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> > 
> > Personally I think CVS*1.21 is a bit too ugly to be worth it.
> 
> Ugly, but for that reason also more legible.  
> 
> Actually, I never noticed the difference between CVS-1.21 and CVS:1.21,
> but I'm pretty sure I would have noticed CVS*1.21.
> 
> An alternative would be CVS-1.21*

The buffer-modified indicator changes from -- to **.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Mode-line customization.

[Richard Stallman]

    > Personally I think CVS*1.21 is a bit too ugly to be worth it.

    Ugly, but for that reason also more legible.  

I don't see anything inherently bad about using a * instead of a colon.
Making it more visible seems to be what people need.

Re: Mode-line customization.

[Stefan Monnier]

>> When you modify a version controlled file in XEmacs, the background of
>> the CVS version becomes highlighted.  In Emacs, it goes from CVS-1.21
>> => CVS:1.21 which isn't obvious

Maybe it's more obvious in XEmacs, but... boy it's ugly!!

Basically, I find that changing the background color on a piece of the
display should be only acceptable under one of the following conditions:
- it is a field-like thingy (as is does for editable stuff in Custom).
- it is done over whole lines.
- it is *really* *really* important for the user to look at it *right now*
  (can't think of any example).
- it is transient (like the region).
- we change the display engine so as to make it less ugly.  One way to do
  that would be to "rounden" ("make round") the corners of the rectangular
  area.


        Stefan

Re: Mode-line customization.

[Peter Whaite]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> When you modify a version controlled file in XEmacs, the background of
> >> the CVS version becomes highlighted.  In Emacs, it goes from CVS-1.21
> >> => CVS:1.21 which isn't obvious

I never noticed that, but I wasn't looking.  I like the idea that there
is a modeline indicator for modified files, but I'm not convinced it
has to be obvious.

Seeing as all this is a matter of personal opinion I find CVS*1.21 ugly
and I dont find CVS:1.21 that pretty either. My preference is CVS+1.21
(mnemonic: additions have been made to version 1.21).

> Maybe it's more obvious in XEmacs, but... boy it's ugly!!

Yeah I agree with this and with Stephan's other comments regarding
background highlighting (well except for the rounded corners thing).

Changing the foreground color would be my choice for a default
customization.


-- 
Peter Whaite (http://whaite.ca)

Re: Mode-line customization.

[Chris Green]

Peter Whaite <emacs@whaite.ca> writes:

> I never noticed that, but I wasn't looking.  I like the idea that there
> is a modeline indicator for modified files, but I'm not convinced it
> has to be obvious.

When I'm in a source tree and tracing down an execution path, I find
it useful to know if I accidentally hit an C-x o when C-x didn't
register and the o ends up in the buffer.   It may not be useful to
you but it has made me do more than 1 revert in my day :)

>
> Seeing as all this is a matter of personal opinion I find CVS*1.21 ugly
> and I dont find CVS:1.21 that pretty either. My preference is CVS+1.21
> (mnemonic: additions have been made to version 1.21).

What about CVS(M):1.21?  Does that take up too much space on the
modeline for people?  I think any small difference of symbol as the
separator will have the same problem of not being noticable.

> Yeah I agree with this and with Stephan's other comments regarding
> background highlighting (well except for the rounded corners thing).

I've found it useful and not particular ugly. After having seen
multiple screenshots of people's editors, I'm pretty convinced that
no one has the same taste.

Since nothing else(?) seems to color the modeline by default in Emacs,
it should probably be some textual indicator with a customizable fg/bg.
-- 
Chris Green <cmg@dok.org>
Eschew obfuscation.

Re: Mode-line customization.

[Masatake YAMATO]

About Mode-line customization, it may be nice to support mouse-face on
mode-line (and header-line).

I've tried to implement mouse-face on mode-line, but it doesn't work perfectly.
I need advices from the display engine experts.

- success:
With the patch, the major mode indicator on mode-line is highlighted 
when the mouse cursor is moved on it. 

- problem:
However, in ruler-mode, current column indicator on header-line is not
highlighted but the character at 0 column on header-line is highlighted
when the mouse cursor is moved on the current column indicator.

Masatake YAMATO
Index: src/xdisp.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.887
diff -u -r1.887 xdisp.c
--- src/xdisp.c	4 May 2004 12:51:45 -0000	1.887
+++ src/xdisp.c	6 May 2004 00:06:20 -0000
@@ -20640,11 +20640,12 @@
    position relative to the start of the mode line.  */
 
 static void
-note_mode_line_or_margin_highlight (w, x, y, area)
-     struct window *w;
+note_mode_line_or_margin_highlight (window, x, y, area)
+     Lisp_Object window;
      int x, y;
      enum window_part area;
 {
+  struct window *w = XWINDOW (window);
   struct frame *f = XFRAME (w->frame);
   Display_Info *dpyinfo = FRAME_X_DISPLAY_INFO (f);
   Cursor cursor = FRAME_X_OUTPUT (f)->nontext_cursor;
@@ -20653,6 +20654,9 @@
   Lisp_Object string, object = Qnil;
   Lisp_Object pos, help;
 
+  Lisp_Object mouse_face;
+  int original_x_pixel = x;
+  
   if (area == ON_MODE_LINE || area == ON_HEADER_LINE)
     string = mode_line_string (w, area, &x, &y, &charpos,
 			       &object, &dx, &dy, &width, &height);
@@ -20728,6 +20732,53 @@
 	  if (!KEYMAPP (map))
 	    cursor = dpyinfo->vertical_scroll_bar_cursor;
 	}
+      
+     /* Change the mouse face according to what is under X/Y.  */
+      mouse_face = Fget_text_property (pos, Qmouse_face, string);
+      if (!NILP (mouse_face) && ((area == ON_MODE_LINE) || (area == ON_HEADER_LINE)))
+	{
+	  Lisp_Object b, e;
+	  struct glyph * glyph;
+	  struct glyph_row *row;
+	  int ignore;
+
+	  if (clear_mouse_face (dpyinfo))
+	    cursor = No_Cursor;
+	  
+	  b = Fprevious_single_property_change(make_number (charpos + 1),
+					       Qmouse_face, string, Qnil);
+	  e = Fnext_single_property_change (pos, Qmouse_face, string, Qnil);
+	  if (NILP (b))
+	    b = make_number (0);
+	  if (NILP (e))
+	    e = make_number (SCHARS (string) - 1);
+
+	  dpyinfo->mouse_face_beg_col = (x - charpos) + XINT(b);
+	  dpyinfo->mouse_face_beg_row = (area == ON_MODE_LINE)? 
+	    (w->current_matrix)->nrows - 1: 
+	    0;
+	  dpyinfo->mouse_face_beg_x   = original_x_pixel - ((charpos  * width) + dx);
+	  dpyinfo->mouse_face_beg_y   = 0;
+	  
+	  dpyinfo->mouse_face_end_col = (x - charpos) + XINT(e) + 1;
+	  dpyinfo->mouse_face_end_row = dpyinfo->mouse_face_beg_row;
+	  dpyinfo->mouse_face_end_x   = 0;
+	  dpyinfo->mouse_face_end_y   = 0;
+	  
+	  dpyinfo->mouse_face_past_end = 0;
+	  dpyinfo->mouse_face_window  = window;
+
+	  row = (area == ON_MODE_LINE)? 
+	    MATRIX_MODE_LINE_ROW (w->current_matrix):
+	    MATRIX_HEADER_LINE_ROW(w->current_matrix);
+	  glyph = row->glyphs[TEXT_AREA] + dpyinfo->mouse_face_beg_col;
+	  dpyinfo->mouse_face_face_id = face_at_string_position(w, string, 
+								charpos,
+								0, 0, 0, &ignore,
+								glyph->face_id, 1);
+
+	  show_mouse_face (dpyinfo, DRAW_MOUSE_FACE);
+	}
     }
 
   define_frame_cursor1 (f, cursor, pointer);
@@ -20806,7 +20857,7 @@
   if (part == ON_MODE_LINE || part == ON_HEADER_LINE
       || part == ON_LEFT_MARGIN || part == ON_RIGHT_MARGIN)
     {
-      note_mode_line_or_margin_highlight (w, x, y, part);
+      note_mode_line_or_margin_highlight (window, x, y, part);
       return;
     }
 
Index: lisp/ruler-mode.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/ruler-mode.el,v
retrieving revision 1.20
diff -u -r1.20 ruler-mode.el
--- lisp/ruler-mode.el	19 Mar 2004 13:15:57 -0000	1.20
+++ lisp/ruler-mode.el	6 May 2004 00:06:20 -0000
@@ -690,6 +690,9 @@
         (aset ruler i ruler-mode-current-column-char)
         (put-text-property
          i (1+ i) 'face 'ruler-mode-current-column-face
+         ruler)
+	(put-text-property
+         i (1+ i) 'mouse-face 'highlight
          ruler))
        ;; Show the `goal-column' marker.
        ((and goal-column (= j goal-column))
Index: lisp/bindings.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.130
diff -u -r1.130 bindings.el
--- lisp/bindings.el	1 May 2004 03:50:24 -0000	1.130
+++ lisp/bindings.el	6 May 2004 00:06:20 -0000
@@ -285,7 +285,7 @@
        (dashes (propertize "--" 'help-echo help-echo)))
   (setq-default mode-line-format
     (list
-     (propertize "-" 'help-echo help-echo)
+     (propertize "-" 'help-echo help-echo 'mouse-face 'highlight)
      'mode-line-mule-info
      'mode-line-modified
      'mode-line-frame-identification
@@ -303,6 +303,7 @@
     (list
      (propertize "%[(" 'help-echo help-echo)
      `(:propertize ("" mode-name)
+		   mouse-face highlight
 		   help-echo "mouse-2: help for current major mode"
 		   local-map ,mode-line-major-mode-keymap)
      '("" mode-line-process)

$HOME default on w32

[Stefan]

It seems that on w32, if HOME is not defined we default it to C:/.
Wouldn't it make more sense to default it to $USERPOFILE (if set) which on XP
seems to typically point to C:/Documents and Files/<user> which is about as
close to a "home directory" as it gets?


        Stefan

Re: $HOME default on w32

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan" <monnier@iro.umontreal.ca>

: It seems that on w32, if HOME is not defined we default it to C:/.
: Wouldn't it make more sense to default it to $USERPOFILE (if set) which on
XP
: seems to typically point to C:/Documents and Files/<user> which is about
as
: close to a "home directory" as it gets?

Good idea!

Re: $HOME default on w32

[CHENG Gao]

,----
| It seems that on w32, if HOME is not defined we default it to C:/.
| Wouldn't it make more sense to default it to $USERPOFILE (if set) which on XP
| seems to typically point to C:/Documents and Files/<user> which is about as
| close to a "home directory" as it gets?
`----

May not be a good idea.

C:/Documents and Settings/<user contains spaces. I am afraid it may cause
problems.

For Emacs, I think installing it to C:/Program Files/ and set HOME to
C:/Documents and Settings/ are both bad ideas. Space in directory name may
cause problems.

And if you store important data in silly M$-registered C:/Documents and
Settings/, then if your computer has fatal problems so that you have to
reinstall, you'll have problems as following:

Say your computer name is "LAZYBONE", and your Windows user  name is "SMARTBOY".

1. If you reinstall Windows, new install wont set C:/Documents and
   Settings/SMARTBOY as your Home dir. Instead it's C:/Documents and
   Settings/SMARTBOY.LAZYBONE/.
   You have to move your data to this new dir.

And I dont think the dir is simply C:/Documents and Settings/<user>, it
may be C:/Documents and Settings/Application Data/ or C:/Documents and
Settings/Local Settings/Application Data/. I am not sure.

2. There is chance that you may format your C: and reinstall Windows
   from scratch. It's highly possible you forget there is so important
   data under this
   too-damned-long-and-silly-named-with-many-stupid-spaces-dir. You know
   what this means.
   I can image that there must be many OE users around the world who
   forget to backup their emails before reinstalling. 

I know I talked too much.

To sum up, I think it's very bad idea to follow this M$ sillie. And if
possible, I think use a subdir under C: should be avoided.
A good choice may be d:/home.

If you are a Windows sufferer, you know you have to reinstall it several
times each year. And every time, you have risk to lose some important
data.

Just my 2 RMB cents.

-- 
这去者，不能见他的脸，背影模糊。

Re: $HOME default on w32

[Stefan Monnier]

> ,----
> | It seems that on w32, if HOME is not defined we default it to C:/.
> | Wouldn't it make more sense to default it to $USERPOFILE (if set) which on XP
> | seems to typically point to C:/Documents and Files/<user> which is about as
> | close to a "home directory" as it gets?
> `----

> May not be a good idea.

> C:/Documents and Settings/<user> contains spaces. I am afraid it may cause
> problems.

My $HOME is set to C:/Documents and Settings/stefan and Emacs works fine.
I know spaces cause difficulties for command line tools, but Windows file
and directory names have spaces and we have to live with it, regardless of
whether we put our home dir there or not.

> 2. There is chance that you may format your C: and reinstall Windows
>    from scratch. It's highly possible you forget there is so important
>    data under this
>    too-damned-long-and-silly-named-with-many-stupid-spaces-dir. You know
>    what this means.
>    I can image that there must be many OE users around the world who
>    forget to backup their emails before reinstalling.

I doubt a Windows user would forget about his own Desktop and "My Documents".
As a matter of fact, for non-Admin users these are about the only directories
where they should have write access.

> To sum up, I think it's very bad idea to follow this M$ sillie. And if
> possible, I think use a subdir under C: should be avoided.  A good choice
> may be d:/home.

Most machines I've seen have no D: drive.

We're talking about a default for non-Unixy users here.  Let's get real.

> If you are a Windows sufferer, you know you have to reinstall it several
> times each year. And every time, you have risk to lose some
> important data.

This is completely irrelevant to this thread.


        Stefan

Re: $HOME default on w32

[Stefan Daschek]

CHENG Gao <chenggao@gmail.com> writes:

> ,----
> | It seems that on w32, if HOME is not defined we default it to C:/.
> | Wouldn't it make more sense to default it to $USERPOFILE (if set) which on XP
> | seems to typically point to C:/Documents and Files/<user> which is about as
> | close to a "home directory" as it gets?
> `----
>
> May not be a good idea.
>
> C:/Documents and Settings/<user contains spaces. I am afraid it may cause
> problems.
>
> For Emacs, I think installing it to C:/Program Files/ and set HOME to
> C:/Documents and Settings/ are both bad ideas. Space in directory name may
> cause problems.

I think I have encountered such problems once or twice, but I consider
them bugs that should be fixed anyway.


> To sum up, I think it's very bad idea to follow this M$ sillie. And if
> possible, I think use a subdir under C: should be avoided.

I don't think so. Users that are aware of the - correct -
disadvantages you mentioned also know how to deal with this problems
(eg. relocate the »My Documents« folder to another partition for
example, or just setting $HOME to another value). Other users will be
confused by any non-standard behaviour, and storing settings outside
$USERPROFILE is non-standard behaviour.


> A good choice may be d:/home.

Very few of the "non power users" I know even have a (writable)
partition "D:", so I think that's a bad idea.


ciao,
noniq

Re: $HOME default on w32

[Kai Grossjohann]

CHENG Gao <chenggao@gmail.com> writes:

> And I dont think the dir is simply C:/Documents and Settings/<user>, it
> may be C:/Documents and Settings/Application Data/ or C:/Documents and
> Settings/Local Settings/Application Data/. I am not sure.

I think there is an environment variable that always points to the
right directory.  Emacs could make %HOME% an alias for that other
environment variable.  Or copy the value of the right variable into
%HOME%.  Or read the right variable in the first place.

Kai

Re: $HOME default on w32

[Stefan Monnier]

>> And I dont think the dir is simply C:/Documents and Settings/<user>, it
>> may be C:/Documents and Settings/Application Data/ or C:/Documents and
>> Settings/Local Settings/Application Data/. I am not sure.

> I think there is an environment variable that always points to the
> right directory.

It's USERPROFILE.  Read my original message.


        Stefan

RE: $HOME default on w32

[Jay Finger]

I think that what you really want is to use SHGetFolderPath() to get the
path to the directory you want.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla
tform/shell/reference/functions/shgetfolderpath.asp

Probably the correct constant to use is CSIDL_PERSONAL, which is the user's
"My Documents" folder.

It is not safe to assume that these well-known folders are somewhere under
c:\documents and settings, or even under $USERPROFILE, as in a networked
environment they may get redirected to someplace so that users can have a
common store.

jay
 
> -----Original Message-----
> From: emacs-devel-bounces+jay.finger=pobox.com@gnu.org [mailto:emacs-
> devel-bounces+jay.finger=pobox.com@gnu.org] On Behalf Of Stefan Monnier
> Sent: Tuesday, October 26, 2004 9:33 AM
> To: Kai Grossjohann
> Cc: emacs-devel@gnu.org
> Subject: Re: $HOME default on w32
> 
> >> And I dont think the dir is simply C:/Documents and Settings/<user>, it
> >> may be C:/Documents and Settings/Application Data/ or C:/Documents and
> >> Settings/Local Settings/Application Data/. I am not sure.
> 
> > I think there is an environment variable that always points to the
> > right directory.
> 
> It's USERPROFILE.  Read my original message.
> 
> 
>         Stefan
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: $HOME default on w32

[Stefan Monnier]

> Probably the correct constant to use is CSIDL_PERSONAL, which is the user's
> "My Documents" folder.

> It is not safe to assume that these well-known folders are somewhere under
> c:\documents and settings, or even under $USERPROFILE, as in a networked
> environment they may get redirected to someplace so that users can have a
> common store.

So what the difference between the two (conceptually) ?
Which one should we use ?
What does it mean if $USERPROFILE points to C:/foo/bar and CSIDL_PERSONAL
points to U:/toto/titi ?  What kind of file should go where ?


        Stefan

Re: $HOME default on w32

[Stephan Stahl]

Hi

Stefan Monnier said:

>> Probably the correct constant to use is CSIDL_PERSONAL, which is the user's
>> "My Documents" folder.
>
>> It is not safe to assume that these well-known folders are somewhere under
>> c:\documents and settings, or even under $USERPROFILE, as in a networked
>> environment they may get redirected to someplace so that users can have a
>> common store.
>
> So what the difference between the two (conceptually) ?
> Which one should we use ?
> What does it mean if $USERPROFILE points to C:/foo/bar and CSIDL_PERSONAL
> points to U:/toto/titi ?  What kind of file should go where ?

As far as i understand it $USERPROFILE points to the place where the
system puts the user files.. (directories like "Cookies",
"Favorites", "Start Menu").
While "My Documents" holds the users own files.

FWIW i use "My Documents" as $HOME because it is the most accessible
place when working with windowze.  Every filedialog has an item "My
Documents", the second folder in the windowze file explorer is "My
Documents".

Since emacs encourages the user to edit his ".emacs" i think it would
be nice to have it in an accessible place.... My 2 cent....

Stephan
-- 
Stephan Stahl

Re: $HOME default on w32

[Cheng Gao]

I know %USERPROFILE% points to user directory.

And I still oppose the idea to use it as $HOME for Emacs.

There are different Windows - 95/98/98SE/Millenium/XP/2003 etc.
As I said, if you need reinstall or upgrade, the result depends on what
Windows you are using. 

It's possible the dir old %USERPROFILE% pointed to may be removed, then
recreated (with same dir names).
It's possible a new dir may be created with COMPUTERNAME or WINDOWS as
suffix and %USERPROFILE% redirected to new dir.

And I think even the most alert user may forget to backup. I know you
are all powerful users, but I dont think all Emacs users are advanced
and alert enough.

After all, it gains very few than using C:\ as $HOME, and has potential
to lose data.


-- 
相濡以沫，不如相忘于江湖。

Re: $HOME default on w32

[Lennart Borgman]

----- Original Message ----- 
From: "Cheng Gao" <chenggao@gmail.com>

: It's possible the dir old %USERPROFILE% pointed to may be removed, then
: recreated (with same dir names).
: It's possible a new dir may be created with COMPUTERNAME or WINDOWS as
: suffix and %USERPROFILE% redirected to new dir.

Does not the use of SHGetFolderPath() with CSIDL_PERSONAL as suggested by
Jay Finger solve this problem?

- Lennart

Re: $HOME default on w32

[Stefan Monnier]

>> So what the difference between the two (conceptually) ?
>> Which one should we use ?
>> What does it mean if $USERPROFILE points to C:/foo/bar and CSIDL_PERSONAL
>> points to U:/toto/titi ?  What kind of file should go where ?

> As far as i understand it $USERPROFILE points to the place where the
> system puts the user files.. (directories like "Cookies",
> "Favorites", "Start Menu").
> While "My Documents" holds the users own files.

> FWIW i use "My Documents" as $HOME because it is the most accessible
> place when working with windowze.  Every filedialog has an item "My
> Documents", the second folder in the windowze file explorer is "My
> Documents".

So there are two issues w.r.t $HOME:
1 - $HOME is used for convenience so the user can access his files with the
    ~ shorthand.
2 - $HOME is used to find user-specific (as opposed to global) settings in
    files such as ~/.emacs.

Number 2 tells us $HOME should be set to $USERPROFILE whereas number 1 would
tend to prefer CSIDL_PERSONAL.

I find number 2 much more important, so I stick to my original idea.


        Stefan

RE: $HOME default on w32

[Jay Finger]

Stefan, I agree with your summary of what the two scenarios are.

CSIDL_PERSONAL (i.e. My Documents) is per-user.  By default this is equal to
"$USERPROFILE\My Documents".  On networked systems My Documents is often
redirected to a user-specific location on the network so that users can have
one directory of data.  The system also does sync'ing so that when offline
(e.g. the laptop is not on the network) the data is still available.

CSIDL_PERSONAL wouldn't be set to have multiple users pointing at one
directory unless an admin really wanted that, in which case I think it would
be ok if emacs followed that.

So I think CSIDL_PERSONAL would meet both 1 and 2.

Just to confuse the issue a little:-) there are two others that you might
want to consider, but I don't think they're correct for $HOME.
CSIDL_APPDATA is application specific data (e.g. where an app might save
it's own metadata that users aren't entirely aware of).  For example,
Microsoft Outlook saves some user settings in
CSIDL_APPDATA\Microsoft\Outlook\...  This directory is by default at
"$USERPROFILE\Application Data", but may roam with the user from machine to
machine.  In other words, it is user specific, but might not be machine
specific.

There is also CSIDL_LOCAL_APPDATA.  It is similar to CSIDL_APPDATA, but with
the promise that it will not roam.  In other words it is both user-specific
and machine-specific.

So, if emacs was trying to get a "Designed for Microsoft Windows XP" logo
:-) it might make sense for some things like saved window configuration or
location of backup files to go into CSIDL_APPDATA\GNU\Emacs\...

Personally, I think that $HOME (~) should be CSIDL_PERSONAL, and that's good
enough for now.

jay

> -----Original Message-----
> From: Stefan Monnier [mailto:monnier@iro.umontreal.ca]
> Sent: Wednesday, October 27, 2004 5:59 AM
> To: Stephan Stahl
> Cc: Jay Finger; 'Kai Grossjohann' ; emacs-devel@gnu.org
> Subject: Re: $HOME default on w32
> 
> >> So what the difference between the two (conceptually) ?
> >> Which one should we use ?
> >> What does it mean if $USERPROFILE points to C:/foo/bar and
> CSIDL_PERSONAL
> >> points to U:/toto/titi ?  What kind of file should go where ?
> 
> > As far as i understand it $USERPROFILE points to the place where the
> > system puts the user files.. (directories like "Cookies",
> > "Favorites", "Start Menu").
> > While "My Documents" holds the users own files.
> 
> > FWIW i use "My Documents" as $HOME because it is the most accessible
> > place when working with windowze.  Every filedialog has an item "My
> > Documents", the second folder in the windowze file explorer is "My
> > Documents".
> 
> So there are two issues w.r.t $HOME:
> 1 - $HOME is used for convenience so the user can access his files with
> the
>     ~ shorthand.
> 2 - $HOME is used to find user-specific (as opposed to global) settings in
>     files such as ~/.emacs.
> 
> Number 2 tells us $HOME should be set to $USERPROFILE whereas number 1
> would
> tend to prefer CSIDL_PERSONAL.
> 
> I find number 2 much more important, so I stick to my original idea.
> 
> 
>         Stefan

Re: $HOME default on w32

[Lennart Borgman]

Jay, if I got you right there is technically no difference between
CSIDL_PERSONAL and CSIDL_APPDATA (except for the location). It is more on
the conceptual side - including the visibility of the folders.
CSIDL_PERSONAL points to "My Documents" which is more visible.

In my opinion "My Documents" is more like $HOME. As a programmer I was quite
a bit frustrated in the beginning before I found "Application Data". So the
choice might depend on the audience.

Actually I feel the division between "My Documents" and "Application Data"
is far better than $HOME that points to both. But of course we can not do
much about that now.

- Lennart



----- Original Message ----- 
From: "Jay Finger" <jay.finger@pobox.com>

: CSIDL_PERSONAL (i.e. My Documents) is per-user.  By default this is equal
to
: "$USERPROFILE\My Documents".  On networked systems My Documents is often
: redirected to a user-specific location on the network so that users can
have
: one directory of data.  The system also does sync'ing so that when offline
: (e.g. the laptop is not on the network) the data is still available.
...
: So I think CSIDL_PERSONAL would meet both 1 and 2.
:
: Just to confuse the issue a little:-) there are two others that you might
: want to consider, but I don't think they're correct for $HOME.
: CSIDL_APPDATA is application specific data (e.g. where an app might save
: it's own metadata that users aren't entirely aware of).  For example,
: Microsoft Outlook saves some user settings in
: CSIDL_APPDATA\Microsoft\Outlook\...  This directory is by default at
: "$USERPROFILE\Application Data", but may roam with the user from machine
to
: machine.  In other words, it is user specific, but might not be machine
: specific.

RE: $HOME default on w32

[Jay Finger]

Yep

> -----Original Message-----
> From: Lennart Borgman [mailto:lennart.borgman.073@student.lu.se]
> Sent: Wednesday, October 27, 2004 10:38 AM
> To: Jay Finger; 'Stefan Monnier'; 'Stephan Stahl'
> Cc: ''Kai Grossjohann' '; emacs-devel@gnu.org
> Subject: Re: $HOME default on w32
> 
> Jay, if I got you right there is technically no difference between
> CSIDL_PERSONAL and CSIDL_APPDATA (except for the location). It is more on
> the conceptual side - including the visibility of the folders.
> CSIDL_PERSONAL points to "My Documents" which is more visible.
> 
> In my opinion "My Documents" is more like $HOME. As a programmer I was
> quite
> a bit frustrated in the beginning before I found "Application Data". So
> the
> choice might depend on the audience.
> 
> Actually I feel the division between "My Documents" and "Application Data"
> is far better than $HOME that points to both. But of course we can not do
> much about that now.
> 
> - Lennart
> 
> 
> 
> ----- Original Message -----
> From: "Jay Finger" <jay.finger@pobox.com>
> 
> : CSIDL_PERSONAL (i.e. My Documents) is per-user.  By default this is
> equal
> to
> : "$USERPROFILE\My Documents".  On networked systems My Documents is often
> : redirected to a user-specific location on the network so that users can
> have
> : one directory of data.  The system also does sync'ing so that when
> offline
> : (e.g. the laptop is not on the network) the data is still available.
> ...
> : So I think CSIDL_PERSONAL would meet both 1 and 2.
> :
> : Just to confuse the issue a little:-) there are two others that you
> might
> : want to consider, but I don't think they're correct for $HOME.
> : CSIDL_APPDATA is application specific data (e.g. where an app might save
> : it's own metadata that users aren't entirely aware of).  For example,
> : Microsoft Outlook saves some user settings in
> : CSIDL_APPDATA\Microsoft\Outlook\...  This directory is by default at
> : "$USERPROFILE\Application Data", but may roam with the user from machine
> to
> : machine.  In other words, it is user specific, but might not be machine
> : specific.
> 

Re: $HOME default on w32

[Stefan Monnier]

> Personally, I think that $HOME (~) should be CSIDL_PERSONAL, and that's good
> enough for now.

>From a Unix point of view, $HOME should be (as far as possible) "the highest
user-specific directory", so that everything that belongs to the user is
below ~.

I think that's why I feel like HOME == USERPROFILE makes more sense.

And since non-user-generated files (like ~/.emacs if it comes from Custom,
or ~/.emacs.d/auto-save-list) are put below $HOME, I feel like "My
Documents" would be wrong.

I have no interest in following W32 practice: I just want to get Emacs
working as well as it can in this inhospitable (because non-Unixy)
environment.  Using C:\ is clearly wrong on systems where C:\ is not
writable or where there are multiple users.


        Stefan

Re: $HOME default on w32

[Peter Whaite]

> > Personally, I think that $HOME (~) should be CSIDL_PERSONAL, and that's good
> > enough for now.
> 
> From a Unix point of view, $HOME should be (as far as possible) "the highest
> user-specific directory", so that everything that belongs to the user is
> below ~.
> 
> I think that's why I feel like HOME == USERPROFILE makes more sense.
> 
> And since non-user-generated files (like ~/.emacs if it comes from Custom,
> or ~/.emacs.d/auto-save-list) are put below $HOME, I feel like "My
> Documents" would be wrong.

I have to agree with Stephan.

David Korn's UWIN also puts HOME under USERPROFILE, and I find that
convenient as its very useful to have your ksh ~/.profile follow you
around when you have a roaming windows profile.  That doesn't happen
with emacs' SYSTEMDRIVE home (and if I recall correctly that's where the
earlier versions of UWIN had it too).

Furthermore it doesn't seem right to put configuration files in "My
Documents" -- its a place for your documents.  Accessing them is natural
with a USERPROFILE home.  Its "~/My Documents".

I definitely dont like the idea of "windows correctness" as that would
place ~/.emacs under something like "USERPROFILE/Application
Data/GNU/Emacs".  Then if you wanted to get to your documents you'd have
to use "~/../../../My Documents/"
   
-- 
Peter Whaite (http://whaite.ca)

Re: $HOME default on w32

[Adrian Aichner]

Peter Whaite <emacs@whaite.ca> writes:

>> > Personally, I think that $HOME (~) should be CSIDL_PERSONAL, and that's good
>> > enough for now.
>> 
>> From a Unix point of view, $HOME should be (as far as possible) "the highest
>> user-specific directory", so that everything that belongs to the user is
>> below ~.
>> 
>> I think that's why I feel like HOME == USERPROFILE makes more sense.
>> 
>> And since non-user-generated files (like ~/.emacs if it comes from Custom,
>> or ~/.emacs.d/auto-save-list) are put below $HOME, I feel like "My
>> Documents" would be wrong.
>
> I have to agree with Stephan.
>
> David Korn's UWIN also puts HOME under USERPROFILE, and I find that
> convenient as its very useful to have your ksh ~/.profile follow you
> around when you have a roaming windows profile.  That doesn't happen

What keeps me from moving my HOME closer to USERPROFILE is the gut
feeling that my XEmacs data is probably safest at maximum distance
from Redmond.

OTOH, it wouldn't be hard for the dark side to check for %HOME% if
they wanted to "upgrade" that data for notepad compatibility :-)

> with emacs' SYSTEMDRIVE home (and if I recall correctly that's where the
> earlier versions of UWIN had it too).
>
> Furthermore it doesn't seem right to put configuration files in "My
> Documents" -- its a place for your documents.  Accessing them is natural
> with a USERPROFILE home.  Its "~/My Documents".
>
> I definitely dont like the idea of "windows correctness" as that would
> place ~/.emacs under something like "USERPROFILE/Application
> Data/GNU/Emacs".  Then if you wanted to get to your documents you'd have
> to use "~/../../../My Documents/"

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

RE: $HOME default on w32

[Jay Finger]

Stefan said
> From a Unix point of view, $HOME should be (as far as possible) "the
> highest
> user-specific directory", so that everything that belongs to the user is
> below ~.
> 
> I think that's why I feel like HOME == USERPROFILE makes more sense.
> 
> And since non-user-generated files (like ~/.emacs if it comes from Custom,
> or ~/.emacs.d/auto-save-list) are put below $HOME, I feel like "My
> Documents" would be wrong.
> 
> I have no interest in following W32 practice: I just want to get Emacs
> working as well as it can in this inhospitable (because non-Unixy)
> environment.  Using C:\ is clearly wrong on systems where C:\ is not
> writable or where there are multiple users.

I don't really understand the statement that '$HOME should be (as far as
possible) "the highest user-specific directory"'.  I certainly get that _is_
that way outside of Windows, but what in emacs' behavior makes you think
$HOME _should be_ as high as possible?

Please don't misunderstand me:  I'm not trying to convert anybody, nor do I
want Emacs behave as a "normal" W32 app.  But I think users will find it
more intuitive if "~" is a directory more likely to have their "stuff".
Those of us with a Unix background will likely not find that any less
convenient than $USERPROFILE, which by itself is already a long sequence of
characters with some spaces.  Personally, the shortcut I use to start emacs
sets the starting folder to where my source trees are (no spaces!) so I at
least have something easy type when I'm in *scratch*.  But I also set $HOME
to My Documents on all my machines because that's where my stuff is.

jay

Re: $HOME default on w32

[Guy Gascoigne - Piggford]

Seconded.  I've used emacs in that configuration for a long time now,  
The spaces don't cause any problems and I've got to say that it's a far 
better default than the root of the drive.

Guy

Lennart Borgman wrote:

>----- Original Message ----- 
>From: "Stefan" <monnier@iro.umontreal.ca>
>
>: It seems that on w32, if HOME is not defined we default it to C:/.
>: Wouldn't it make more sense to default it to $USERPOFILE (if set) which on
>XP
>: seems to typically point to C:/Documents and Files/<user> which is about
>as
>: close to a "home directory" as it gets?
>
>Good idea!
>
>
>
>_______________________________________________
>Emacs-devel mailing list
>Emacs-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
>
>  
>

Re: $HOME default on w32

[Jason Rumney]

Stefan <monnier@iro.umontreal.ca> writes:

> It seems that on w32, if HOME is not defined we default it to C:/.
> Wouldn't it make more sense to default it to $USERPOFILE (if set)
> which on XP seems to typically point to C:/Documents and
> Files/<user> which is about as close to a "home directory" as it gets?

The thought has occured to me in the past.

We'd need to make sure that existing users who have Emacs related
files in C:\ are accounted for. We could perhaps have the installer
offer to move their files to $USERPROFILE, but do we know the full set
of files we might have to move (including files for external tools
that inherit the Emacs process environment when run from Emacs)?

The other (easier and hopefully less error prone) option is to check
at startup if c:\.emacs exists when defaulting HOME. Is it realistic
to expect that a user has no other files in HOME that would be
affected if .emacs does not yet exist?

Re: $HOME default on w32

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>

: Stefan <monnier@iro.umontreal.ca> writes:
:
: > It seems that on w32, if HOME is not defined we default it to C:/.
: > Wouldn't it make more sense to default it to $USERPOFILE (if set)
: > which on XP seems to typically point to C:/Documents and
: > Files/<user> which is about as close to a "home directory" as it gets?
:
: The thought has occured to me in the past.
:
: We'd need to make sure that existing users who have Emacs related
: files in C:\ are accounted for. We could perhaps have the installer
: offer to move their files to $USERPROFILE, but do we know the full set
: of files we might have to move (including files for external tools
: that inherit the Emacs process environment when run from Emacs)?
:
: The other (easier and hopefully less error prone) option is to check
: at startup if c:\.emacs exists when defaulting HOME. Is it realistic
: to expect that a user has no other files in HOME that would be
: affected if .emacs does not yet exist?

I believe the easier route is the way to go! I think the check for c:\.emacs
is enough.

- Lennart

calendar problems

[Karl Chen]

Something has broken in `mark-diary-entries' such that (setq
mark-diary-entries-in-calendar t) and related no longer work
correctly.  It seems to be setting point to the beginning of the
calendar buffer (I think the previous behavior was to leave it on
the current date.)

-- 
Karl 2005-03-10 13:38

Re: calendar problems

[Alan Shutko]

Karl Chen <quarl@cs.berkeley.edu> writes:

> Something has broken in `mark-diary-entries' such that (setq
> mark-diary-entries-in-calendar t) and related no longer work
> correctly.  It seems to be setting point to the beginning of the
> calendar buffer (I think the previous behavior was to leave it on
> the current date.)

I see the same thing, and Glenn and I have exchanged some emails.  I'm
still trying to track down where exactly point is getting moved.  It's
related to the recent change to do a redraw when marking diary
entries.  

-- 
Alan Shutko <ats@acm.org> - I am the rocks.

Re: calendar problems

[Ed Reingold]

> > Something has broken in `mark-diary-entries' such that (setq
> > mark-diary-entries-in-calendar t) and related no longer work
> > correctly.  It seems to be setting point to the beginning of the
> > calendar buffer (I think the previous behavior was to leave it on
> > the current date.)
> 
> I see the same thing, and Glenn and I have exchanged some emails.  I'm
> still trying to track down where exactly point is getting moved.  It's
> related to the recent change to do a redraw when marking diary
> entries.  

What recent change?!  I thought all changes were going to be cleared through 
me.

Re: calendar problems

[Alan Shutko]

Ed Reingold <reingold@emr.cs.iit.edu> writes:

> What recent change?!  I thought all changes were going to be cleared through 
> me.

Glenn Morris is currently listed as maintainer.  I don't know when
this changed.

;; Maintainer: Glenn Morris <gmorris@ast.cam.ac.uk>


-- 
Alan Shutko <ats@acm.org> - I am the rocks.

Re: calendar problems

[Richard Stallman]

    What recent change?!  I thought all changes were going to be cleared through 
    me.

You stopped maintaining the calendar code long ago, so I asked
Glenn Morris to maintain it.  He has been doing this for a year,
and doing a good job.

Re: calendar problems

[Ed Reingold]

> You stopped maintaining the calendar code long ago, so I asked
> Glenn Morris to maintain it.  He has been doing this for a year,
> and doing a good job.

*I* never stopped anything.

Re: calendar problems

[Richard Stallman]

I think I recall you even said you were not interested
in doing some of the work that needed doing--so I had
to look for someone else.

RMAIL slows

[Robert J. Chassell]

Sunday's GNU Emacs CVS snapshot, Sun, 2005 Mar 13
GNU Emacs 22.0.50.22 (i686-pc-linux-gnu, GTK+ Version 2.6.2)

vrs

Friday's GNU Emacs CVS snapshot, Fri, 2005 Mar 18
GNU Emacs 22.0.50.26 (i686-pc-linux-gnu, GTK+ Version 2.6.2)

    both started with the same, long .emacs file

Deletion in RMAIL slows after an instance of GNU Emacs has been
running for several days.  The time to delete the same 50 messages,
all marked with `d', is double in the five day older instance than in
the newer instance.

This has been going on for months, but I have not been able to find
the bug.  That is why I have not reported this earlier.  I cannot find
anything wrong with Emacs!

There are no memory leaks that I can find and the backtraces are
nearly the same, being different only in addresses.

When deleting 50 messages, I found that in the older instance, each
call to `rmail-summary-goto-msg' takes nearly twice the Elapsed Time
as in the newer instance of Emacs,

Here are the five most frequently called functions from when I
instrumented `rmail-summary-' using `elp' and deleted 50 messages (the
same messages from the same RMAIL file each time):

older

Function Name                        Call Count  Elapsed Time  Average Time
===================================  ==========  ============  ============
rmail-summary-update-highlight       156         0.0032450000  2.080...e-05
rmail-summary-goto-msg               150         3.5518869999  0.0236792466
rmail-summary-exists                 51          0.0013599999  2.666...e-05
rmail-summary-displayed              50          0.0023839999  4.767...e-05
rmail-summary-mark-deleted           50          0.1103629999  0.00220726


younger
Function Name                        Call Count  Elapsed Time  Average Time
===================================  ==========  ============  ============
rmail-summary-update-highlight       166         0.0089219999  5.374...e-05
rmail-summary-goto-msg               153         1.9204319999  0.0125518431
rmail-summary-exists                 56          0.0013960000  2.492...e-05
rmail-summary-displayed              52          0.0021609999  4.155...e-05
rmail-summary-mark-deleted           50          0.0944409999  0.0018888199

The time sink is `rmail-summary-goto-msg'. 

I profiled one deletion on that function.  `rmail-summary-goto-msg'
continues as the time sink.  The function takes longer over time.

older
Function Name                        Call Count  Elapsed Time  Average Time
===================================  ==========  ============  ============
rmail-summary-goto-msg               6           0.057814      0.0096356666
rmail-summary-rmail-update           6           0.0381699999  0.0063616666
rmail-summary-undelete               1           0.016846      0.016846
rmail-summary-delete-forward         1           0.013405      0.013405


younger
Function Name                        Call Count  Elapsed Time  Average Time
===================================  ==========  ============  ============
rmail-summary-construct-io-menu      1           0.141289      0.141289
rmail-summary-rmail-update           8           0.0816259999  0.0102032499
rmail-summary-delete-forward         1           0.032636      0.032636
rmail-summary-goto-msg               4           0.0205899999  0.0051474999

Unfortunately, I am now lost.  On glancing at the source for
`rmail-summary-goto-msg' I don't see anything obviously wrong.  What
should I do next?

I normally do not run an instance of Emacs so long, since I like to
update and run new CVS versions.  But I will keep this older version
sitting on my desktop ready for any tests you might suggest.



Here is the backtrace for the older instance.  In both instances, I
went to the most recent message, # 247, then to the previous message,
then to the next (i.e., most recent message) again, then suspended the
instance and ran `bt'.

Program received signal SIGTSTP, Stopped (user).
0x407eee12 in select () from /lib/libc.so.6
(gdb) bt
#0  0x407eee12 in select () from /lib/libc.so.6
#1  0x00000007 in ?? ()
#2  0x00000000 in ?? ()
#3  0xbfffef20 in ?? ()
#4  0x081b2069 in wait_reading_process_output (time_limit=157, microsecs=0, 
    read_kbd=-1, do_display=1, wait_for_cell=137576249, wait_proc=0x0, 
    just_wait_proc=0) at process.c:4350
#5  0x0808a957 in sit_for (sec=157, usec=0, reading=1, display=1, 
    initial_display=0) at dispnew.c:6367
#6  0x081220d6 in read_char (commandflag=1, nmaps=4, maps=0xbffff19c, 
    prev_event=137576249, used_mouse_menu=0xbffff1d8) at keyboard.c:2769
#7  0x08128b64 in read_key_sequence (keybuf=0xbffff300, bufsize=30, 
    prompt=137576249, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:8803
#8  0x0811f323 in command_loop_1 () at keyboard.c:1538
#9  0x081806fe in internal_condition_case (bfun=0x811f190 <command_loop_1>, 
    handlers=137637249, hfun=0x811ec80 <cmd_error>) at eval.c:1385
#10 0x0811efde in command_loop_2 () at keyboard.c:1319
#11 0x081801fb in internal_catch (tag=-514, func=0x811efb0 <command_loop_2>, 
    arg=137576249) at eval.c:1144
#12 0x0811ef83 in command_loop () at keyboard.c:1298
#13 0x0811e9e4 in recursive_edit_1 () at keyboard.c:991
#14 0x0811eb21 in Frecursive_edit () at keyboard.c:1052

Here is the backtrace of the first four stack frames of the newer
instance, just to show you its near identity with the backtrace of the
older instance.

Program received signal SIGTSTP, Stopped (user).
0x407eee12 in select () from /lib/libc.so.6
(gdb) bt
#0  0x407eee12 in select () from /lib/libc.so.6
#1  0x00000000 in ?? ()
#2  0x00000000 in ?? ()
#3  0xbfffef20 in ?? ()
#4  0x081b2239 in wait_reading_process_output (time_limit=157, microsecs=0, 
    read_kbd=-1, do_display=1, wait_for_cell=137573145, wait_proc=0x0, 
    just_wait_proc=0) at process.c:4350

As I said, I cannot find anything wrong with either instance of Emacs
except that RMAIL deletions in the older instance take longer and
longer.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Sunday's GNU Emacs CVS snapshot, Sun, 2005 Mar 13
> GNU Emacs 22.0.50.22 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
>
> vrs
>
> Friday's GNU Emacs CVS snapshot, Fri, 2005 Mar 18
> GNU Emacs 22.0.50.26 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
>
>     both started with the same, long .emacs file
>
> The time sink is `rmail-summary-goto-msg'. 
>
> I profiled one deletion on that function.  `rmail-summary-goto-msg'
> continues as the time sink.  The function takes longer over time.
>
> older
> Function Name                        Call Count  Elapsed Time  Average Time
> ===================================  ==========  ============  ============
> rmail-summary-goto-msg               6           0.057814      0.0096356666
> rmail-summary-rmail-update           6           0.0381699999  0.0063616666
> rmail-summary-undelete               1           0.016846      0.016846
> rmail-summary-delete-forward         1           0.013405      0.013405
>
>
> younger
> Function Name                        Call Count  Elapsed Time  Average Time
> ===================================  ==========  ============  ============
> rmail-summary-construct-io-menu      1           0.141289      0.141289
> rmail-summary-rmail-update           8           0.0816259999  0.0102032499
> rmail-summary-delete-forward         1           0.032636      0.032636
> rmail-summary-goto-msg               4           0.0205899999  0.0051474999
>
> Unfortunately, I am now lost.  On glancing at the source for
> `rmail-summary-goto-msg' I don't see anything obviously wrong.  What
> should I do next?

Well, one thing that appears wrong is that the branch that calls
rmail-summary-goto-msg recursively then still goes on to continue
working afterwards.

I don't have enough of a clue to judge whether this is intended
behavior, but it certainly appears weird.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: RMAIL slows

[Richard Stallman]

    Deletion in RMAIL slows after an instance of GNU Emacs has been
    running for several days.  The time to delete the same 50 messages,
    all marked with `d', is double in the five day older instance than in
    the newer instance.

You said "deletion", but do you really mean "expunging"?
It looks that way.

The info you got with the profiler doesn't tell us much.  What you
need to do is find out where in the code the slowness is occurring.

Since rmail-summary-goto-msg contains no loops, if it gets slower
the slowness must be in a subroutine.  Since you did not see it in ELP,
it must be within a primitive written in C.

You could try running under GDB, doing the slow operation, and
stopping it with C-z to make a backtrace.  If you set up a loop to
call some summary command over and over, you will be able to type C-z
and make a backtrace as much as you like.  After you do it a few
times, you should see a pattern.

    Here is the backtrace for the older instance.  In both instances, I
    went to the most recent message, # 247, then to the previous message,
    then to the next (i.e., most recent message) again, then suspended the
    instance and ran `bt'.

Since you made that backtrace when Emacs was waiting, not during the
operation in question, it tells nothing relevant to the issue.

Re: RMAIL slows

[Robert J. Chassell]

   You said "deletion", but do you really mean "expunging"?
   It looks that way.

I meant using the `rmail-summary-delete-forward' which is bound to `d',
i.e., deleting, not expunging.

   ... Since you did not see it in ELP, it must be within a primitive
   written in C. . .. try running under GDB ...

The primitive that appears in the backtraces from the older instance,
but not the newer is

    re_match_2_internal

which is in emacs/src/regex.c.  

I do not understand the function.  My impression is that the maximum
size of the match data store should be 30 items, but I do not know how
big each item could be or whether large items could slow my machine.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

    The primitive that appears in the backtraces from the older instance,
    but not the newer is

	re_match_2_internal

    which is in emacs/src/regex.c.  

That is the inner function that does regexp matching.  Could you
please show a backtrace of the inner 5 or 10 C stack frames that call
it?  Then we will see which C primitive was called.

Also, by looking at the args to that C primitive, you can see
what the regexp is.

Re: RMAIL slows

[Robert J. Chassell]

            re_match_2_internal

    ... is the inner function that does regexp matching.  Could you
    please show a backtrace of the inner 5 or 10 C stack frames that call
    it?  Then we will see which C primitive was called.

    Also, by looking at the args to that C primitive, you can see
    what the regexp is.

Is this what you mean?

(gdb) bt
#0  re_match_2_internal (bufp=0x8329a5c, 
    string1=0x42078bab "Subject: wicked drug)s to keep you going\nFrom: \"Terrance Hampton\" <hampton_lr@sympatico.ca>\nDate: Tue, 22 Mar 2005 11:29:57 +0000\nTo: ackahn@rattlesnake.com\n\nWelcome!\n\nIts time to stop wasting money o"..., 
    size1=0, 
    string2=0x42078bab "Subject: wicked drug)s to keep you going\nFrom: \"Terrance Hampton\" <hampton_lr@sympatico.ca>\nDate: Tue, 22 Mar 2005 11:29:57 +0000\nTo: ackahn@rattlesnake.com\n\nWelcome!\n\nIts time to stop wasting money o"..., 
    size2=797, pos=6, regs=0x8320ea8, stop=0) at regex.c:4835
#1  0x08163f82 in re_search_2 (bufp=0x8329a5c, 
    str1=0x42078bab "Subject: wicked drug)s to keep you going\nFrom: \"Terrance Hampton\" <hampton_lr@sympatico.ca>\nDate: Tue, 22 Mar 2005 11:29:57 +0000\nTo: ackahn@rattlesnake.com\n\nWelcome!\n\nIts time to stop wasting money o"..., 
    size1=0, 
    str2=0x42078bab "Subject: wicked drug)s to keep you going\nFrom: \"Terrance Hampton\" <hampton_lr@sympatico.ca>\nDate: Tue, 22 Mar 2005 11:29:57 +0000\nTo: ackahn@rattlesnake.com\n\nWelcome!\n\nIts time to stop wasting money o"..., 
    size2=797, startpos=6, range=791, regs=0x8320ea8, stop=797) at regex.c:4328
#2  0x0815a265 in search_buffer (string=151866368, pos=6316886, pos_byte=0, 
    lim=6317683, lim_byte=6318289, n=1, RE=1, trt=143145540, 
    inverse_trt=143150548, posix=1107790763) at search.c:1138
#3  0x08159a69 in search_command (string=144968947, bound=137576249, 
    noerror=137576297, count=1107790763, direction=1, RE=1, posix=0)
    at search.c:939
#4  0x0815c07e in Fre_search_forward (regexp=1107790763, bound=1107790763, 
    noerror=1107790763, count=1107790763) at search.c:2160


I am not sure what to do next.  I tried this:

(gdb) c
Continuing.

Breakpoint 6, Fre_search_forward (regexp=137779403, bound=137779403, 
    noerror=137779403, count=137779403) at search.c:2160
2160      return search_command (regexp, bound, noerror, count, 1, 1, 0);
(gdb) bt
#0  Fre_search_forward (regexp=137779403, bound=137779403, noerror=137779403, 
    count=137779403) at search.c:2160

And

(gdb) f 0
#0  Fre_search_forward (regexp=137779403, bound=137779403, noerror=137779403, 
    count=137779403) at search.c:2160
2160      return search_command (regexp, bound, noerror, count, 1, 1, 0);
(gdb) list
2155    See also the functions `match-beginning', `match-end', `match-string',
2156    and `replace-match'.  */)
2157         (regexp, bound, noerror, count)
2158         Lisp_Object regexp, bound, noerror, count;
2159    {
2160      return search_command (regexp, bound, noerror, count, 1, 1, 0);
2161    }
2162    
2163    DEFUN ("posix-search-backward", Fposix_search_backward, Sposix_search_backward, 1, 4,
2164           "sPosix search backward: ",
(gdb) info f
Stack level 0, frame at 0xbfffddd0:
 eip = 0x815c041 in Fre_search_forward (search.c:2160); saved eip 0x8182499
 called by frame at 0xbfffde40
 source language c.
 Arglist at 0xbfffddc8, args: regexp=137779403, bound=137779403, 
    noerror=137779403, count=137779403
 Locals at 0xbfffddc8, Previous frame's sp is 0xbfffddd0
 Saved registers:
  ebp at 0xbfffddc8, eip at 0xbfffddcc
(gdb) info args
regexp = 137779403
bound = 137779403
noerror = 137779403
count = 137779403

I also tried printing the value of `regexp=137779403' and got

(gdb) p
$3 = 137779403

I do not know what to try next.  What should I do?

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Stefan Monnier]

>             re_match_2_internal
>     ... is the inner function that does regexp matching.  Could you
>     please show a backtrace of the inner 5 or 10 C stack frames that call
>     it?  Then we will see which C primitive was called.

>     Also, by looking at the args to that C primitive, you can see
>     what the regexp is.

> Is this what you mean?

Check emacs/etc/DEBUG for more info about what to do,


        Stefan

Re: RMAIL slows

[Richard Stallman]

    #4  0x0815c07e in Fre_search_forward (regexp=1107790763, bound=1107790763, 
	noerror=1107790763, count=1107790763) at search.c:2160


    I am not sure what to do next.  I tried this:

You need to display the value of regexp in Lisp syntax.  That is done
with the pr command.

Haven't you read etc/DEBUG?

Re: RMAIL slows

[Robert J. Chassell]

       I am not sure what to do next.  I tried this:

   You need to display the value of regexp in Lisp syntax.  That is done
   with the pr command.

The problem is that I saw

    (gdb) pr
    17213013

which did not seem as useful.  That is why I showed the results of 

      (gdb) pp regexp=137779403
and 
      (gdb) p *$

For a person as ignorant as I, `emacs/etc/DEBUG' does not go far
enough in telling me what to do in this case.  The file helps in other
cases.  But in this case, I am trying to try to find out why an older
instance of Emacs runs the command `rmail-summary-delete-forward' more
slowly than newer instance of the same version.

It is likely that you understand what is to be done and consider it
obvious; unfortunately, I do not.

Please, tell me what you would like me to do, understanding that I
know nothing.  I will undertake the actions you suggest and try to
write a appropriate section for `emacs/etc/DEBUG' for people like me.

Thank you.

Meanwhile, in another instance of Emacs, but from the same binary and
also taking a long time to run the command
`rmail-summary-delete-forward', I set the breakpoint as before at
regex.c:4168 .

Then:

  (gdb) c
  Continuing.

  Program received signal SIGTSTP, Stopped (user).
  re_match_2_internal (bufp=0x8329d8c, 
      string1=0x40af4785 ....

  (gdb) p string1=0x40af4785
  $1 = (
      const unsigned char *) 0x40af4785 "Date: Tue, 22 Mar 2005 15:36:30 +0300 (MSK)\nFrom: MAILER-DAEMON@mtu.ru (Mail Delivery System)\nSubject: Undelivered Mail Returned to Sender\nTo: edd@rattlesnake.com\n\nThis is a MIME-encapsulated message."...

This gave a different result for pr:

  (gdb) pr
  (88425796 . 
  Program received signal SIGSEGV, Segmentation fault.
  0x08193800 in print_object (obj=1952531466, printcharfun=137657281, 
      escapeflag=1) at print.c:1981
  1981          switch (XMISCTYPE (obj))
  ...

The warning in `emacs/etc/DEBUG' mentions a stack overflow,
however, the backtrace did not show any

  (gdb) bt
  #0  0x08193800 in print_object (obj=1952531466, printcharfun=137657281, 
      escapeflag=1) at print.c:1981
  #1  0x08194d1a in print_object (obj=1952531466, printcharfun=137657281, 
      escapeflag=1) at print.c:1792
  #2  0x08191897 in Fprin1 (object=1085228933, printcharfun=137657281)
      at print.c:742
  #3  0x08192ada in debug_print (arg=1952531464) at print.c:965
  #4  <function called from gdb>
  #5  re_match_2_internal (bufp=0x8329d8c, 
      string1=0x40af4785 "Date: Tue, 22 Mar 2005 15:36:30 +0300 (MSK)\nFrom: MAILER-DAEMON@mtu.ru (Mail Delivery System)\nSubject: Undelivered Mail Returned to Sender\nTo: edd@rattlesnake.com\n\nThis is a MIME-encapsulated message."..., 
      size1=0, 
  ...

So I tried:

  (gdb)     break print.c:1981
  Breakpoint 4 at 0x81937fb: file print.c, line 1981.

  (gdb) c
  Continuing.
  Fatal error (11)
  Breakpoint 3, re_search_2 (bufp=0x832907c, 
      str1=0x8a32850 "/home/bob/.emacs.d/auto-save-list/.saves-11154-benthic.rattlesnake.com~", size1=71, str2=0x0, size2=71, startpos=0, range=144655563, 
      regs=0x4072a080, stop=143356597) at regex.c:4176
  4176    {

  (gdb) p str1=0x8a32850
  $2 = 0x8a32850 "/home/bob/.emacs.d/auto-save-list/.saves-11154-benthic.rattlesnake.com~"

  (gdb) pr
  18113802

  (gdb) p 18113802      
  $3 = 18113802

  (gdb) pr

  Breakpoint 4, print_object (obj=18113802, printcharfun=137657281, escapeflag=1)
      at print.c:1981
  1981          switch (XMISCTYPE (obj))
  ...

  (gdb) xbacktrace
  "re-search-forward"
  "goto-address-fontify"
  "goto-address"
  "run-hooks"
  "rmail-show-message"
  "rmail-summary-goto-msg"
  "rmail-summary-delete-forward"
  "call-interactively"

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

I am too overloaded to tell you step by step by email what debugger
commands to type.  Maybe someone else can do it.

      (gdb) p string1=0x40af4785

that told GDB to set the value of string1
to 0x40af4785.  I don't think that's what you meant.

      (gdb) pr
      (88425796 . 

That got an error because the value had the wrong type.
It is a string, not a Lisp_Object.  You need to examine
regexp, the argument passed to Fre_search_...

Re: RMAIL slows

[Robert J. Chassell]

         (gdb) p string1=0x40af4785

   that told GDB to set the value of string1
   to 0x40af4785.  I don't think that's what you meant.

         (gdb) pr
         (88425796 .

   That got an error because the value had the wrong type.
   It is a string, not a Lisp_Object.  ...

My apologies; I misunderstood what to do.  On looking further

  re_match_2_internal

does appear to be the relevant function.

Meanwhile, by accident, on a CVS rebuild I did a `make bootstrap'
rather than a `make bootfast' and thereby deleted the slow instance of
emacs that I was using.  I hope to get back to you next week.  (As I
said, none of the Emacs code looks wrong to me.  An instance of RMAIL
takes several days and several thousand spam mail messages to slow.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Robert J. Chassell]

    ... , by accident, ... I .. deleted the slow instance of emacs
    that I was using. ...

OK, I am back.  [Problem: over time, a batch deletion of 50 or 100
RMAIL files takes longer and longer.  This slow down only happens
after an instance of Emacs has been running for several days.  New
instances are quick.  Unfortunately, Emacs looks fine to me.]

Using GDB, the bug seems to be in

    re_match_2_internal 

which is in emacs/src/regex.c on line 4828
That function is called by 

    re_search_2 

which is called by 

    search_buffer

On stepping through `re_match_2_internal', I do not see anything
wrong.  However, the function contains 1255 lines and I do not
understand it.  There may be something obvious in there which I do not
see.  Or maybe the problem comes from somewhere else and I am being
fooled.  Anyhow, I cannot figure out the bug.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Stefan Monnier]

> OK, I am back.  [Problem: over time, a batch deletion of 50 or 100
> RMAIL files takes longer and longer.  This slow down only happens
> after an instance of Emacs has been running for several days.  New
> instances are quick.  Unfortunately, Emacs looks fine to me.]

> Using GDB, the bug seems to be in

>     re_match_2_internal 

OK, here is some info that might help you get info that's more useful:

There are several possible cases:
- some code calls re_match_2_internal more often over time.
  I.e. the calls to re_match_2_internal do not get slower themselves,
  so the problem is elsewhere.

- the calls to re_match_2_internal get slower for some reason.
  This may be because:
  - the regexp changes over time.
  - the text matched changes over time.
  - some side-data makes the code slower over time.

Now, re_match_2_internal is a function that can easily take an insane amount
of time to terminate (its complexity is exponential), depending mostly on
the regexp used.  It's a misfeature, but we do not usually consider it as
a bug, and instead we try to avoid pathological cases.

So a good thing to do is to look at the regexp that's being matched
(typically: look up the backtrace to see the value of the `string' argument
to search_buffer, then do "print string" and then "xstring" to see the
actual string).  If you don't know how to recognize regexps that can lead to
pathological exponential behavior, post it here.
Another good thing to do is to look at the text being matched (look at some
of the char* variables).

Another good thing to do is to say "finish" to let the code run until the
end of re_match_2_internal.  If it's immediate it means the problem is maybe
not in the time taken in each call to re_match_2_internal, but rather in the
number of calls.


        Stefan

Re: RMAIL slows

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> ... look up the backtrace to see the value of the `string' argument
> to search_buffer, then do "print string" and then "xstring" to see the
> actual string).

Or just do "pp string".

> Another good thing to do is to say "finish" to let the code run until the
> end of re_match_2_internal.  If it's immediate it means the problem is maybe
> not in the time taken in each call to re_match_2_internal, but rather in the
> number of calls.

The "xbacktrace" command may also give you some ideas in which lisp
function the loop may be.  You can interrupt emacs several times
and see if all calls to regexp happens in the same sequence of
function calls.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: RMAIL slows

[Robert J. Chassell]

Stefan Monnier <monnier@iro.umontreal.ca> wrote, 

   ... re_match_2_internal is a function that can easily take an
   insane amount of time ...

   So a good thing to do is to look at the regexp that's being matched
   (typically: look up the backtrace to see the value of the `string' argument
   to search_buffer, then do "print string" and then "xstring" to see the
   actual string).  

Thank you.  This and Kim's message are what I need.  I cannot figure
out why things go wrong.  They look OK to me.

    ... let the code run until the end of re_match_2_internal.  If
    it's immediate it means the problem is maybe not in the time taken
    in each call to re_match_2_internal, but rather in the number of
    calls.

When I evoke `finish' when the program has stopped at
re_match_2_internal, it runs fairly quickly to then stop in
re_search_2 in regex.c, line 4338, at the second line of 

      if (val >= 0)
	return startpos;

even though I do not have a break point there.  (The only breakpoint
for this run is in re_match_2_internal at regex.c:4828)

I am returning fairly quickly from `finish' so the problem may be in
the number of calls, not in re_match_2_internal.  I am deleting 100
messages per batch.  The point is, such a deletion is quick for a
fresh instance of Emacs but slow after that instance of Emacs has been
running for several days.


In any event, here first is     search_buffer  then  re_match_2_internal 


1. Here is the backtrace from a break for     search_buffer
   ( break search.c:1051 ), followed by
        (gdb) c
        (gdb) print string
        (gdb) xstring
        (gdb) finish

#0  search_buffer (string=189937, pos=137573113, pos_byte=137573161, lim=137573113, lim_byte=1, n=1, RE=0, trt=135730036, inverse_trt=-1073747680, posix=188026) at search.c:1051
#1  0x08159be9 in search_command (string=144556139, bound=137573113, noerror=137573161, count=188026, direction=1, RE=1, posix=0) at search.c:939
#2  0x0815c1fe in Fre_search_forward (regexp=188026, bound=188026, noerror=188026, count=188026) at search.c:2160

(gdb) c
Continuing.

Breakpoint 3, search_buffer (string=189937, pos=137573113, pos_byte=137573161, lim=137573113, lim_byte=1, n=1, RE=0, trt=135730036, inverse_trt=-1073747680, posix=188026) at search.c:1051

(gdb) print string
$1 = 189937

(gdb) xstring
$2 = (struct Lisp_String *) 0x2e5f0
Cannot access memory at address 0x2e5fc

(gdb) finish
Run till exit from #0  search_buffer (string=189937, pos=137573113, pos_byte=137573161, lim=137573113, lim_byte=1, n=1, RE=0, trt=135730036, inverse_trt=-1073747680, posix=188026) at search.c:1051
search_command (string=144556139, bound=137573113, noerror=137573161, count=188893, direction=1, RE=1, posix=0) at search.c:947
Value returned is $3 = 188893

(gdb) pp string
"\\<\\(ftp://\\|http://\\|gopher://\\|news:\\|nntp:\\|telnet://\\|wais://\\|file:/\\|prospero:\\|z39.50s:\\|z39.50r:\\|cid:\\|mid:\\|vemmi:\\|service:\\|imap:\\|nfs:\\|acap:\\|rtsp:\\|tip:\\|pop:\\|data:\\|dav:\\|opaquelocktoken:\\|sip:\\|tel:\\|fax:\\|modem:\\|ldap:\\|https://\\|soap.beep:\\|soap.beeps:\\|urn:\\|go:\\|afs:\\|tn3270:\\|mailserver:\\|snews:\\)[^]	
 \"'()<>[^`{}]*[^]	
 \"'()<>[^`{}.,;]+"

(gdb) xbacktrace
"re-search-forward"
"goto-address-fontify"
"goto-address"
"run-hooks"
"rmail-show-message"
"rmail-summary-goto-msg"
"rmail-summary-delete-forward"
"call-interactively"





2. Then I put in a break for     re_match_2_internal 

    (gdb) break regex.c:4828

    and continued.  Here is the backtrace and the results of 
        (gdb) print string1
        (gdb) xstring
        (gdb) finish

    The match is to a spam mail that is in the test mbox I am using.

#0  re_match_2_internal (bufp=0x83298cc, string1=0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\277\201\370\201\300\201\273\201\300\201\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"..., size1=0, string2=0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\277\201\370\201\300\
 201\273\201\300\201\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"..., size2=1911, pos=867, regs=0x414, stop=0) at regex.c:4835
#1  0x08164102 in re_search_2 (bufp=0x83298cc, str1=0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\277\201\370\201\300\201\273\201\300\201\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"..., size1=0, str2=0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\277\201\370\201\300\
 201\273\201\300\201\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"..., size2=1911, startpos=872, range=1039, regs=0x8320268, stop=1911) at regex.c:4328
#2  0x0815a3e5 in search_buffer (string=140965112, pos=188893, pos_byte=867, lim=189937, lim_byte=189937, n=1, RE=1, trt=142892020, inverse_trt=142937924, posix=1084985957) at search.c:1138

(gdb) print string1
$4 = (const unsigned char *) 0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\277\201\370\201\300\201\273\201\300\201\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"...

(gdb) xstring
Argument to arithmetic operation not a number or boolean.

(gdb) finish
Run till exit from #0  re_match_2_internal (bufp=0x83298cc, string1=0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\277\201\370\201\300\201\273\201\300\201\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"..., size1=0, string2=0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\2
 77\201\370\201\300\201\273\201\300\201\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"..., size2=1911, pos=867, regs=0x414, stop=0) at regex.c:4835
re_search_2 (bufp=0x83298cc, str1=0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\277\201\370\201\300\201\273\201\300\201\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"..., size1=0, str2=0x40ab9265 "From: \"\201\274\201\256\201\301\201\370\201\277\201\3549\" <singer1002@naver.com>\nReply-To: \"\201\261\201\350\201\271\201\316\201\305\201\3029\" <qpoijong@nate.com>\nTo: bob@rattlesnake.com\nSubject: \201\301\201\367\201\300\201\345\201\300\201\316,\201\260\201\370\201\271\201\253\201\277\201\370\201\300\201\273\201\300\20
 1\247\201\307\201\321\201\267\201\320\201\300\201\316\201\306\201\367,\201\303\201\326\201\260\201\355\201\300\201\307\201\307\201\375\201\305\201\303 \201\277\201\3710"..., size2=1911, startpos=872, range=1039, regs=0x8320268, stop=1911) at regex.c:4337
Value returned is $5 = -1


What should I do next?

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Stefan Monnier]

> (gdb) xbacktrace
> "re-search-forward"
> "goto-address-fontify"
> "goto-address"
> "run-hooks"
> "rmail-show-message"
> "rmail-summary-goto-msg"
> "rmail-summary-delete-forward"
> "call-interactively"

Is it possible that the slow down is cause by goto-address?


        Stefan

Re: RMAIL slows

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> wrote, 
>
>    ... re_match_2_internal is a function that can easily take an
>    insane amount of time ...
>
>    So a good thing to do is to look at the regexp that's being matched
>    (typically: look up the backtrace to see the value of the `string' argument
>    to search_buffer, then do "print string" and then "xstring" to see the
>    actual string).  
>
> Thank you.  This and Kim's message are what I need.  I cannot figure
> out why things go wrong.  They look OK to me.
>
>     ... let the code run until the end of re_match_2_internal.  If
>     it's immediate it means the problem is maybe not in the time taken
>     in each call to re_match_2_internal, but rather in the number of
>     calls.
>
> When I evoke `finish' when the program has stopped at
> re_match_2_internal, it runs fairly quickly to then stop in
> re_search_2 in regex.c, line 4338, at the second line of 
>
>       if (val >= 0)
> 	return startpos;
>
> even though I do not have a break point there.  (The only breakpoint
> for this run is in re_match_2_internal at regex.c:4828)

Please compile Emacs with "-fnocrossjumping" in the CFLAGS options.
If you don't, GCC will merge multiple execution paths, making
debugging returns, assertions and other stuff quite impossible.

Stack traces will tend to be occasionally rubbish, too.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: RMAIL slows

[Robert J. Chassell]

David Kastrup <dak@gnu.org>

    Please compile Emacs with "-fnocrossjumping" in the CFLAGS options.

I am doing that now.  (Presuming today's CVS compiles without error.)
If all goes well, I will run this new instance of Emacs for several
days or a week until RMAIL slows enough and then investigate.

I will check Stefan's question whether the slow down is caused by
goto-address, too.

Many thanks!  This is the kind of help I need.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

I wonder if the slowness is due to an increasing number of markers
or overlays in the buffer.  Maybe goto-address is making them and
never getting rid of them.

Re: RMAIL slows

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I wonder if the slowness is due to an increasing number of markers
> or overlays in the buffer.  Maybe goto-address is making them and
> never getting rid of them.

If that were the case, then one symptom might be that performance
improves when setting gc-cons-threshold to a _smaller_ value, such as
1000.  Then Emacs would collect garbage (and consequently unused
markers slowing down the operation) quite more often.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: RMAIL slows

[Richard Stallman]

    > I wonder if the slowness is due to an increasing number of markers
    > or overlays in the buffer.  Maybe goto-address is making them and
    > never getting rid of them.

    If that were the case, then one symptom might be that performance
    improves when setting gc-cons-threshold to a _smaller_ value, such as
    1000.  Then Emacs would collect garbage (and consequently unused
    markers slowing down the operation) quite more often.

If it is cumulative over a period of days, they are not getting GC'd.
Markers that are pointed to would not get GC'd.
Overlays would not get GC'd.

Re: RMAIL slows

[Robert J. Chassell]

       If that were the case, then one symptom might be that performance
       improves when setting gc-cons-threshold to a _smaller_ value
       ... 

   If it is cumulative over a period of days, they are not getting GC'd.

It has been cumulative over days.  I'll evaluate 

    (garbage-collect)

every day for several days and see whether RMAIL deletions slow down.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

    It has been cumulative over days.  I'll evaluate 

	(garbage-collect)

    every day for several days and see whether RMAIL deletions slow down.

I think you need not bother to test this, because the answer is clear.
Emacs certainly collects garbage many times each day.

You might try killing the Rmail buffer and visiting the file again,
in the old session.  Does this make it get fast again?

Re: RMAIL slows

[Robert J. Chassell]

[markers and overlays not getting GC'd]
I just had a chance to work with RMAIL again.

   You might try killing the Rmail buffer and visiting the file again,
   in the old session.  Does this make it get fast again?

If it does, it is only a very little.  I am not sure whether it does
or whether the little difference is my imagination.

However, after killing that instance of Emacs and starting a new
instance, rmail sped up dramatically.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

       You might try killing the Rmail buffer and visiting the file again,
       in the old session.  Does this make it get fast again?

    If it does, it is only a very little.  I am not sure whether it does
    or whether the little difference is my imagination.

    However, after killing that instance of Emacs and starting a new
    instance, rmail sped up dramatically.

Well, there goes my guess.  We can only await more information from
you.

If you do xbacktrace while Rmail is doing whatever takes up the time,
you should get some useful information for us.  You need to do this
enough times so that you see a pattern.

Re: RMAIL slows

[Robert J. Chassell]

   If you do xbacktrace while Rmail is doing whatever takes up the
   time, you should get some useful information for us.

OK: over four deletions (50 messages each, plenty of time to suspend
for GDB), the constant is "rmail-reformat-message".  Here is what I
saw:

    (gdb) xbacktrace
    "rmail-clear-headers"
    "rmail-reformat-message"
    "rmail-show-message"

    (gdb) xbacktrace
    "rmail-clear-headers"
    "rmail-reformat-message"
    "rmail-show-message"

    (gdb) xbacktrace
    "rmail-reformat-message"
    "rmail-show-message"
    "rmail-summary-goto-msg"

    (gdb)  xbacktrace
    "rmail-reformat-message"
    "rmail-show-message"
    "rmail-summary-goto-msg"

I am going to have to reboot my system (changing a device), so it will
be a few days before anything slows down again.  When I restart, I'll
use the same emacs/src/emacs executable from 2005 Mar 30, but the
latest CVS .el files.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

    OK: over four deletions (50 messages each, plenty of time to suspend
    for GDB), the constant is "rmail-reformat-message".  Here is what I
    saw:

This is interesting.

I think you said it was spending most of the time in regexp matching.
Is that right?  If so, can you determine what regexp it spends most of
its time matching?  That way we could see precisely where it is in the
code.

Re: RMAIL slows

[Robert J. Chassell]

[After running the same RMAIL for several days, deletions slow; but
not immediately.  Using the `emacs/src/emacs' executable of 2005 Mar
30.]

   I think you said it was spending most of the time in regexp matching.
   Is that right?  If so, can you determine what regexp it spends most of
   its time matching? ...

Here are three instances.  Each instance involved deleting 50 messages
each and suspending in the middle of the action for GDB.

In instances 1 and 3, `xbacktrace' showed "rmail-reformat-message".
Instance 2 did not.

In instance 1, `backtrace' (not `xbacktrace') showed
"adjust_markers_for_delete"; the other two instances showed
"re_match_2_internal".


## Instance 1

(gdb) xbacktrace
"delete-char"
"rmail-reformat-message"
"rmail-show-message"
"rmail-summary-goto-msg"
"rmail-summary-delete-forward"
"call-interactively"

(gdb) bt
#0  adjust_markers_for_delete (from=6865840, from_byte=6865840, to=6865841, to_byte=6865841) at insdel.c:353
#1  0x0814113b in del_range_2 (from=6865840, from_byte=6865840, to=6865841, to_byte=6865841, ret_string=0) at insdel.c:1946
#2  0x08140d94 in del_range_1 (from=6865840, to=6865841, prepare=1, ret_string=8310629) at insdel.c:1813


## Instance 2

(gdb) xbacktrace
"re-search-forward"
"goto-address-fontify"
"goto-address"
"run-hooks"
"rmail-show-message"
"rmail-summary-goto-msg"
"rmail-summary-delete-forward"
"call-interactively"

(gdb) bt
#0  re_match_2_internal (bufp=0x83291ac, string1=0x41152088 "From: Service de distribution du courrier <postmaster@laposte.net>\nSubject: =?ISO-8859-15?Q?Notification_d'=E9tat_de_la_distribution?=\nTo: terencio@rattlesnake.com\nDate: Sun, 24 Apr 2005 07:07:49 +020"..., size1=202, string2=0x41152fb3 "\nCe message MIME en plusieurs parties contient une notification d'\201\303\201\251tat de distribution.\nSi vous voyez ce texte, il est possible que votre client de courrier ne puisse pas\nlire les messages MIME for"..., size2=1856, pos=2013, regs=0x8320268, stop=2058) at regex.c:4944
#1  0x08164102 in re_search_2 (bufp=0x83291ac, str1=0x41152088 "From: Service de distribution du courrier <postmaster@laposte.net>\nSubject: =?ISO-8859-15?Q?Notification_d'=E9tat_de_la_distribution?=\nTo: terencio@rattlesnake.com\nDate: Sun, 24 Apr 2005 07:07:49 +020"..., size1=202, str2=0x41152fb3 "\nCe message MIME en plusieurs parties contient une notification d'\201\303\201\251tat de distribution.\nSi vous voyez ce texte, il est possible que votre client de courrier ne puisse pas\nlire les messages MIME for"..., size2=1856, startpos=2013, range=45, regs=0x8320268, stop=2058) at regex.c:4328

## Instance 3

(gdb) xbacktrace

"re-search-forward"
"rmail-clear-headers"
"rmail-reformat-message"
"rmail-show-message"
"rmail-summary-goto-msg"
"rmail-summary-delete-forward"
"call-interactively"

(gdb) bt
#0  0x081660e5 in re_match_2_internal (bufp=0x832907c, string1=0x410f0d43 "Date: Sun, 24 Apr 2005 03:26:04 +0300\nFrom: \"Melba Andrade\" <ziaciidyia@tucsonalarm.com>\nSubject: Agenda for 2005: ReManufactured toner market\nTo: Decklin <decklin@red-bean.com>\nMIME-version: 1.0\nX-Ma"..., size1=0, string2=0x410f0d43 "Date: Sun, 24 Apr 2005 03:26:04 +0300\nFrom: \"Melba Andrade\" <ziaciidyia@tucsonalarm.com>\nSubject: Agenda for 2005: ReManufactured toner market\nTo: Decklin <decklin@red-bean.com>\nMIME-version: 1.0\nX-Ma"..., size2=557, pos=156, regs=0x8320268, stop=0) at regex.c:5631
#1  0x08164102 in re_search_2 (bufp=0x832907c, str1=0x410f0d43 "Date: Sun, 24 Apr 2005 03:26:04 +0300\nFrom: \"Melba Andrade\" <ziaciidyia@tucsonalarm.com>\nSubject: Agenda for 2005: ReManufactured toner market\nTo: Decklin <decklin@red-bean.com>\nMIME-version: 1.0\nX-Ma"..., size1=0, str2=0x410f0d43 "Date: Sun, 24 Apr 2005 03:26:04 +0300\nFrom: \"Melba Andrade\" <ziaciidyia@tucsonalarm.com>\nSubject: Agenda for 2005: ReManufactured toner market\nTo: Decklin <decklin@red-bean.com>\nMIME-version: 1.0\nX-Ma"..., size2=557, startpos=156, range=401, regs=0x8320268, stop=557) at regex.c:4328

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

These three show three different situations.  In one,
rmail-reformat-message has called delete-char.  In another,
rmail-reformat-message has called rmail-clear-headers.  The other is
in goto-address and not in rmail-reformat-message at all.

One of these is probably the thing that takes the extra time
that causes the slowdown.  What you need to do is figure out
which one it is.  Then please focus *only* on that case
and ignore the other cases.

Re: RMAIL slows

[Robert J. Chassell]

[After running the same RMAIL for several days, deletions slow; but
not immediately.  Using the `emacs/src/emacs' executable of 2005 Mar
30.]

    ... figure out which [function] it is.

Well, I am not 100% sure which function causes the problem, since
sometimes GDB stops in some other function, but the most common
`xbacktrace' shows:

    "rmail-clear-headers"
    "rmail-reformat-message"
    "rmail-show-message"
    "rmail-summary-goto-msg"
    "rmail-summary-delete-forward"
    "call-interactively"

and  `bt' shows

#0  0x0813ecf9 in adjust_markers_for_delete (from=2643804, from_byte=2643804, to=2643822, to_byte=2643822) at insdel.c:353
#1  0x0814113b in del_range_2 (from=2643804, from_byte=2643804, to=2643822, to_byte=2643822, ret_string=0) at insdel.c:1946
#2  0x08140d94 in del_range_1 (from=2643804, to=2643822, prepare=1, ret_string=461697) at insdel.c:1813
#3  0x08140d07 in del_range (from=141387496, to=141387496) at insdel.c:1780
#4  0x0817a7f0 in Fdelete_region (start=21150432, end=21150576) at editfns.c:2937

I put a breakpoint in `adjust_markers_for_delete' and looped at least 8
times.

I tried looking at the items around the breakpoint, insdel.c:353,
which is at

    if (charpos > Z)

Evidentally both charpos and Z are defined in src/buffer.h.  Z is the end
of the buffer and is not exceeded.

charpos is the marker.

The test is part of a loop testing various conditions, the first of
which is whether the position exceeds the end of the buffer.

  for (m = BUF_MARKERS (current_buffer); m; m = m->next)


In `struct buffer_text' in src/buffer.h, charpos is defined on line 346 as

    /* The markers that refer to this buffer.
       This is actually a single marker ---
       successive elements in its marker `chain'
       are the other markers referring to this buffer.  */
    struct Lisp_Marker *markers;

so it looks to me that a long list of markers accumulates over time.

But I do not know enough.  I may be quite wrong about all of this.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Stefan Monnier]

> so it looks to me that a long list of markers accumulates over time.

Sounds credible.  Can you go to the RMAIL buffer and try something like

 (length (save-restriction (widen) (overlays-in (point-min) (point-max))))

to see how many overlays are in the buffer?  Overlays are often the main
cause of accumulation of markers.


        Stefan

Re: RMAIL slows

[Robert J. Chassell]

   ... Can you go to the RMAIL buffer and try something like

    (length (save-restriction (widen) (overlays-in (point-min) (point-max))))

   to see how many overlays are in the buffer?

6128

That is more than I expected.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Kevin Rodgers]

Robert J. Chassell wrote:
>    ... Can you go to the RMAIL buffer and try something like
> 
>     (length (save-restriction (widen) (overlays-in (point-min) (point-max))))
> 
>    to see how many overlays are in the buffer?
> 
> 6128
> 
> That is more than I expected.

How many did you expect?

-- 
Kevin Rodgers

Re: RMAIL slows

[Robert J. Chassell]

    > ... Can you go to the RMAIL buffer and try something like
    > 
    > (length (save-restriction (widen) (overlays-in (point-min) (point-max))))

    > 6128

    How many did you expect?

Under 1000.  Now my RMAIL has slowed even more and I have 13604 overlays.

I will follow RMS' suggestion, but it may be a few days before my
RMAIL slows again enough.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Stefan Monnier]

>> ... Can you go to the RMAIL buffer and try something like
>> (length (save-restriction (widen) (overlays-in (point-min) (point-max))))
>> 6128
>     How many did you expect?
> Under 1000.  Now my RMAIL has slowed even more and I have 13604 overlays.

Looks like it may be the culprit.  Could you try and take a look at those
overlays to see what they look like?
If you just

  (pp (save-restriction (widen) (overlays-in (point-min) (point-max)))
      (get-buffer-create "*overlays*"))

and then look at the *overlays* buffer, you should be able to see the
start/end points of those overlays, so you can at least see if
they're empty.  You maybe also want to check whether some/many of them seem
to be piled up one of top of the other.

Further than that you'll have to use `overlay-properties' on some of
those overlays to get an idea of where they come from and what they're
supposed to do.


        Stefan

Re: RMAIL slows

[Robert J. Chassell]

Stefan Monnier <monnier@iro.umontreal.ca> suggested

    If you just

        (pp
         (save-restriction
           (widen)
           (overlays-in (point-min)
                        (point-max)))
         (get-buffer-create "*overlays*"))

    and then look at the *overlays* buffer, you should be able to see
    the start/end points of those overlays, so you can at least see if
    they're empty.  You maybe also want to check whether some/many of
    them seem to be piled up one of top of the other.

Here is part of what I see:

#<overlay from 2144619 to 2144619 in RMAIL> #<overlay from 2144619 to 2144619 in RMAIL> #<overlay from 2144619 to 2144619 in RMAIL> #<overlay from 2144619 to 2144619 in RMAIL> #<overlay from 2144619 to 2144619 in RMAIL>)

These overlap dramatically.

    Further than that you'll have to use `overlay-properties' on some
    of those overlays to get an idea of where they come from and what
    they're supposed to do.

OK.  The following

    (pp
     (save-restriction
       (widen)
       (overlay-properties (car (overlays-in 2144619 2144619))))
     (get-buffer-create "*overlays-1*"))

shows this:

    (goto-address t keymap
                  (keymap
                   (3 keymap
                      (13 . goto-address-at-point))
                   (mouse-2 . goto-address-at-mouse))
                  help-echo "mouse-2, C-c RET: mail this address" mouse-face secondary-selection face italic)

which is the same as looking at the `nth 2' and `nth 6' overlays.

I do have the following in my .emacs file:

    (add-hook 'rmail-show-message-hook 'goto-address)

When I comment that out and start a fresh instance of Emacs, I see
just this in my *overlays* buffer for the same RMAIL file on the same
message:

(#<overlay from 1938742 to 1938772 in RMAIL> #<overlay from 1938656 to 1938670 in RMAIL>)

These overlays do not overlap.

Moreover, 

    (pp
     (save-restriction
       (widen)
       (overlay-properties 
        (car 
         (overlays-in (point-min)
                      (point-max)))))
     (get-buffer-create "*overlays*"))

shows

    (face bold)

which is the same as for `nth 1'.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Stefan Monnier]

>     and then look at the *overlays* buffer, you should be able to see
>     the start/end points of those overlays, so you can at least see if
>     they're empty.  You maybe also want to check whether some/many of
>     them seem to be piled up one of top of the other.

> Here is part of what I see:

> #<overlay from 2144619 to 2144619 in RMAIL> #<overlay from 2144619 to 2144619 in RMAIL> #<overlay from 2144619 to 2144619 in RMAIL> #<overlay from 2144619 to 2144619 in RMAIL> #<overlay from 2144619 to 2144619 in RMAIL>)

> These overlap dramatically.

Not only they overlap but they're empty.
Would 2144619 happen to be at/near the end of the RMAIL buffer (or at/near
the last position of the buffer every displayed)?

Maybe we just need to make goto-address mark its overlay with the
`evaporate' propert so they disappear as soon as they beomce empty.

I doubt it's going to be sufficient, bu it may be a good start.


        Stefan


--- orig/lisp/net/goto-addr.el
+++ mod/lisp/net/goto-addr.el
@@ -165,6 +165,7 @@
                      (this-overlay (make-overlay s e)))
 		(and goto-address-fontify-p
                      (overlay-put this-overlay 'face goto-address-url-face))
+                (overlay-put this-overlay 'evaporate t)
 		(overlay-put this-overlay
                              'mouse-face goto-address-url-mouse-face)
 		(overlay-put this-overlay
@@ -179,6 +180,7 @@
                      (this-overlay (make-overlay s e)))
 		(and goto-address-fontify-p
                      (overlay-put this-overlay 'face goto-address-mail-face))
+                (overlay-put this-overlay 'evaporate t)
                 (overlay-put this-overlay 'mouse-face
                              goto-address-mail-mouse-face)
 		(overlay-put this-overlay

Re: RMAIL slows

[Robert J. Chassell]

   >     and then look at the *overlays* buffer,

   Not only they overlap but they're empty.

   Would 2144619 happen to be at/near the end of the RMAIL buffer (or at/near
   the last position of the buffer every displayed)?

Yes.  I am not sure whether that number came when I was at the end or
near the end.

Thank you for the patch.  I will try a new instance of Emacs with the
hook for goto-address in my .emacs and with your fix.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Robert J. Chassell]

[After running the same RMAIL for several days, deletions slow; but
they do not slow the first day.]

Success so far!

On 6 May 2005, Stefan Monnier said

    Maybe we just need to make goto-address mark its overlay with the
    `evaporate' propert so they disappear as soon as they beomce
    empty.

and provided a patch.

Using that patch, RMAIL deletions have been fast.

At the moment, I have only 155 overlays in the RMAIL buffer rather
than the many thousands as before.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Should overlays evaporate by default?

[Peter Whaite]

Robert J. Chassell <bob@rattlesnake.com> wrote:
> [After running the same RMAIL for several days, deletions slow; but
> they do not slow the first day.]
> 
> Success so far!
> 
> On 6 May 2005, Stefan Monnier said
> 
>     Maybe we just need to make goto-address mark its overlay with the
>     `evaporate' propert so they disappear as soon as they beomce
>     empty.
> 
> and provided a patch.

Last year I reported a similar problem with mh-e (see below).

Perhaps it would be better for overlays to evaporate by default.

I can only think of one case where its not better, and that's where the
contents of an editable field are deleted and new contents reinserted.
If the overlay evaporates the field disappears, but the bug is
immediately obvious and quickly fixed.

On the other hand, for the case where overlays are used to decorate
buffer contents, the consequence (massive memory leakage) is not
obvious, and goes undetected.  I suspect that this case is far more
common.

For reference here is what I said back on 15 July 2004:
>
> MH-E uses parts of GNUS to display messages, and the overlays used by
> GNUS do not have the evaporate property set, and so do not get deleted
> when the mh-show buffer is erased in preparation for the next message
> (see below).
> 
> Yes MH-E, and any other packages that use these utilities, could be
> changed to explicitly delete overlays when reusing buffers, but it would
> be easier for maintainers and future package writers if the GNUS
> overlays would evaporate.
> 
> It would not surprise me if other packages using overlays to decorate
> buffer contents also leak.
> 
> The real problem is that anyone using overlays to decorate the contents
> of a reusable buffer is required to know that they must either
> explicitly set the evaporate property on any overlays they create, or
> explicitly delete overlays when using erase-buffer, or both.
> 
> This requirement is not obvious.  There should be a note in the
> erase-buffer documentation pointing out that only overlays with the
> evaporate property will be deleted, and with a reference to the new
> remove-overlays function.
> 
> I think it preferable that erase-buffer also remove the overlays.  Right
> now it results in _all_ the non-evaporating overlays being reduced to
> zero length at the begining of the buffer.  Inserting text into the
> buffer cannot ressurect them unless they have a non-default end
> advance behaviour.  I guess erase-buffer could be selective about which
> overlays it removes, but that sounds like overkill as I doubt anyone
> intentionally uses overlays and erase-buffer that way.
> 
> Here is the result of my tests on the MH-E message show buffer after
> using it to browse several email messages...
> 
> (pp (save-current-buffer
>   (set-buffer (get-buffer-create "show-+inbox"))
>   (mapcar (lambda (ov) (list (overlay-start ov) (overlay-end ov)
>   	  	       	     (overlay-properties ov)))
> 	  (overlays-in (point-min) (point-max)))
>   ))
> 
> Overlays used in current message...
> 
> ((515 558
>       (face gnus-cite-face-2))
>  (443 512
>       (face gnus-cite-face-2))
>  (378 437
>       (face gnus-cite-face-2))
>  (302 374
>       (face gnus-cite-attribution-face))
>  (302 374
>       (face gnus-cite-face-2))
> 
> Overlays used in previous messages...
> 
>  (1 1
>     (face gnus-cite-face-2))
>  (1 1
>     (face gnus-cite-face-2))
>  (1 1
>     (face gnus-cite-attribution-face))
>  (1 1
>     (face gnus-cite-face-3))
>  (1 1
>     (keymap
>      (keymap
>       (mouse-2 . smiley-mouse-toggle-buffer)
>       (down-mouse-2 . ignore))
>      help-echo "mouse-2: toggle smilies in buffer" smiley t mouse-face highlight display
>      (when smiley-active image :type pbm :file "/usr/local/share/emacs/21.3.50/lisp/gnus/smile.pbm" :ascent center)))
>     (face gnus-cite-face-2))
> 
>   ...and many, many, more
> )

-- 
Peter Whaite (http://whaite.ca)

Re: Should overlays evaporate by default?

[Richard Stallman]

    Perhaps it would be better for overlays to evaporate by default.

I tend to agree this would make things better in most cases, and only
be wrong in a few.  However, it is an incompatible change, and in some
places it WILL break code.

It occur to me that we could make it easier to find those places.
Suppose that by default the `evaporate' property is set to `display-warning'.
Suppose that in this case, when the overlay becomes empty, it evaporates
and displays a warning using `display-warning'.

On seeing the warningm programmers would adapt their programs to set
`evaporate' either to t or nil and thus prevent the warning.

In Emacs 23, we could change the default to t.

Re: Should overlays evaporate by default?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Perhaps it would be better for overlays to evaporate by default.
>
> I tend to agree this would make things better in most cases, and only
> be wrong in a few.  However, it is an incompatible change, and in some
> places it WILL break code.

And so, we shouldn't do ANYTHING about it in 22.x

>
> It occur to me that we could make it easier to find those places.
> Suppose that by default the `evaporate' property is set to `display-warning'.
> Suppose that in this case, when the overlay becomes empty, it evaporates
> and displays a warning using `display-warning'.

We can do that immediately AFTER the release.

>
> On seeing the warningm programmers would adapt their programs to set
> `evaporate' either to t or nil and thus prevent the warning.
>
> In Emacs 23, we could change the default to t.

Eventually, just before the 23.x release, yes.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Should overlays evaporate by default?

[Richard Stallman]

    > It occur to me that we could make it easier to find those places.
    > Suppose that by default the `evaporate' property is set to `display-warning'.
    > Suppose that in this case, when the overlay becomes empty, it evaporates
    > and displays a warning using `display-warning'.

    We can do that immediately AFTER the release.

Why would it be better then than now?
No matter when we do it, it will cause some programs
to issue these warnings.  People will have to report them
so we can fix them.  The natural time to do that will be
in pretesting.  We will soon (I hope) do pretesting.
Why postpone this till the pretest of the subsequent version?

If this were a new feature, I would say let's put it off.
But it is not a feature but a way of finding bugs, such as
the bug that Bob and others tracked down with so much effort
and time.

This change would involve some work.  We would have to
check all 136 or so calls to make-overlay or its synonyms
in the Emacs sources, and change each of them to DTRT
with the overlay property.  That's a substantial job
and maybe nobody wants to do it.

Re: Should overlays evaporate by default?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > It occur to me that we could make it easier to find those places.
>     > Suppose that by default the `evaporate' property is set to `display-warning'.
>     > Suppose that in this case, when the overlay becomes empty, it evaporates
>     > and displays a warning using `display-warning'.
>
>     We can do that immediately AFTER the release.
>
> Why would it be better then than now?

> No matter when we do it, it will cause some programs
> to issue these warnings.  People will have to report them
> so we can fix them.  The natural time to do that will be
> in pretesting.  We will soon (I hope) do pretesting.

We do "pretesting" all the time with CVS emacs -- there are
many ordinary users using it already for everyday work.

> Why postpone this till the pretest of the subsequent version?

Because it will delay releasing 22.x.

>
> If this were a new feature, I would say let's put it off.
> But it is not a feature but a way of finding bugs, such as
> the bug that Bob and others tracked down with so much effort
> and time.

It is not a new feature, and so the bugs it causes are not
new either -- if we hope to fix every possible bug before
releasing 22.x, it will never be ready!

> This change would involve some work.  We would have to
> check all 136 or so calls to make-overlay or its synonyms
> in the Emacs sources, and change each of them to DTRT
> with the overlay property.  That's a substantial job
> and maybe nobody wants to do it.

I don't have time.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Should overlays evaporate by default?

[Richard Stallman]

    We do "pretesting" all the time with CVS emacs -- there are
    many ordinary users using it already for everyday work.

It is not the same.  A different and larger group of people will start
trying a wider range of Lisp packages when we start formal pretest.
We will find bugs then that have not been noticed hitherto.

    > Why postpone this till the pretest of the subsequent version?

    Because it will delay releasing 22.x.

It would cause a delay to the extent that the work necessary to fix
the code would take some time.  It is not clear to me that it is
better for that time to occur later than now.  But if no one wants to
do this work, then the question is moot.

I am not sure this thing is really the right thing to do, at any time.
It could be more trouble than it is worth, and we might prefer just
to find the things that fail to reclaim their overlays.

Re: Should overlays evaporate by default?

[Peter Whaite]

Richard Stallman <rms@gnu.org> wrote:
>
> I am not sure this thing is really the right thing to do, at any time.
> It could be more trouble than it is worth, and we might prefer just
> to find the things that fail to reclaim their overlays.

I suspect most overlays already have an explicit evaporate property
set but I dont know.  Richards suggestion would at least tell us that.

I thought I would quickly try it out, but all the overlay defuns are in
C code and it would require a fair bit of effort on my part to become
familiar with the C mechanisms (how to set, get properties, invoke other
defuns, etc.), and I dont have that much time.

The little I have read about defadvice suggests it might do for some
preliminary tests.  Can someone advise me if thats the case?

-- 
Peter Whaite (http://whaite.ca)

Re: Should overlays evaporate by default?

[Richard Stallman]

    I thought I would quickly try it out, but all the overlay defuns are in
    C code and it would require a fair bit of effort on my part to become
    familiar with the C mechanisms (how to set, get properties, invoke other
    defuns, etc.), and I dont have that much time.

If you want to try out such patches, I suppose someone here would be
willing to write the patches for you to try.

Re: Should overlays evaporate by default?

[Peter Whaite]

Richard Stallman <rms@gnu.org> wrote:
>     I thought I would quickly try it out, but all the overlay defuns are in
>     C code and it would require a fair bit of effort on my part to become
>     familiar with the C mechanisms (how to set, get properties, invoke other
>     defuns, etc.), and I dont have that much time.
> 
> If you want to try out such patches, I suppose someone here would be
> willing to write the patches for you to try.

I would be willing to try patches, and that would help me get up to
speed faster.

If everyone is to busy with other things, could I use defadvice to
instrument the overlay functions instead?

-- 
Peter Whaite (http://whaite.ca)

Re: Should overlays evaporate by default?

[Richard Stallman]

    If everyone is to busy with other things, could I use defadvice to
    instrument the overlay functions instead?

I don't know to what extent that will work, but you could try it.

Re: Should overlays evaporate by default?

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

> patches for you to try.

below is an untested patch that sets the evaporate property
for newly-made overlays.  munge to taste, etc.

thi

___________________________________________________________
*** buffer.c    4 May 2005 22:10:14 -0000       1.479
--- buffer.c    18 May 2005 00:13:24 -0000
***************
*** 3602,3607 ****
--- 3602,3611 ----
    XOVERLAY (overlay)->plist = Qnil;
    XOVERLAY (overlay)->next = NULL;
  
+   /* This is suitable for testing.  If it works out, we can
+      rework it to set ->plist directly (a few lines above).  */
+   Foverlay_put (overlay, Qevaporate, Qt); 
+ 
    /* Put the new overlay on the wrong list.  */
    end = OVERLAY_END (overlay);
    if (OVERLAY_POSITION (end) < b->overlay_center)

Re: Should overlays evaporate by default?

[Richard Stallman]

    below is an untested patch that sets the evaporate property
    for newly-made overlays.  munge to taste, etc.

This sets the property to t.
That is not what we are looking for now.

The goal now is to *find* possible bugs.
The patch should set the property to something unusual (maybe
`never-set') by default.  When such an overlay becomes empty, there
should be some sort of warning.  That way, people will find code
that perhaps ought to set the evaporate property to something
explicitly.

Re: Should overlays evaporate by default?

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

> The goal now is to *find* possible bugs.
> The patch should set the property to something unusual (maybe
> `never-set') by default.  When such an overlay becomes empty, there
> should be some sort of warning.  That way, people will find code
> that perhaps ought to set the evaporate property to something
> explicitly.

ok, below is a patch to buffer.c that does this, more or less.  the
(%d,%d) is perhaps redundant, but since we're in the checking mood...

thi

___________________________________________________________
*** buffer.c	4 May 2005 22:10:14 -0000	1.479
--- buffer.c	19 May 2005 08:14:13 -0000
***************
*** 178,183 ****
--- 178,189 ----
  Lisp_Object Qinsert_in_front_hooks;
  Lisp_Object Qinsert_behind_hooks;
  
+ #define OVERLAY_EVAPORATE_TESTING
+ #ifdef OVERLAY_EVAPORATE_TESTING
+ Lisp_Object Qnever_set;
+ static Lisp_Object evaporate_overlay P_ ((Lisp_Object));
+ #endif
+ 
  static void alloc_buffer_text P_ ((struct buffer *, size_t));
  static void free_buffer_text P_ ((struct buffer *b));
  static struct Lisp_Overlay * copy_overlays P_ ((struct buffer *, struct Lisp_Overlay *));
***************
*** 3602,3607 ****
--- 3608,3617 ----
    XOVERLAY (overlay)->plist = Qnil;
    XOVERLAY (overlay)->next = NULL;
  
+ #ifdef OVERLAY_EVAPORATE_TESTING
+   Foverlay_put (overlay, Qevaporate, Qnever_set);
+ #endif
+ 
    /* Put the new overlay on the wrong list.  */
    end = OVERLAY_END (overlay);
    if (OVERLAY_POSITION (end) < b->overlay_center)
***************
*** 3656,3661 ****
--- 3666,3689 ----
  \f
  Lisp_Object Fdelete_overlay ();
  
+ #ifdef OVERLAY_EVAPORATE_TESTING
+ static Lisp_Object
+ evaporate_overlay (overlay)
+      Lisp_Object overlay;
+ {
+   if (EQ (Qnever_set, Foverlay_get (overlay, Qevaporate)))
+     {
+       char msg[256];
+       sprintf (msg, "WARNING: overlay (%d,%d) evaporating unexpectedly",
+                OVERLAY_POSITION (OVERLAY_START (overlay)),
+                OVERLAY_POSITION (OVERLAY_END (overlay)));
+       message (msg);
+     }
+ 
+   return Fdelete_overlay (overlay);
+ }
+ #endif
+ 
  static struct Lisp_Overlay *
  unchain_overlay (list, overlay)
       struct Lisp_Overlay *list, *overlay;
***************
*** 3704,3710 ****
    CHECK_NUMBER_COERCE_MARKER (end);
  
    if (XINT (beg) == XINT (end) && ! NILP (Foverlay_get (overlay, Qevaporate)))
!     return Fdelete_overlay (overlay);
  
    if (XINT (beg) > XINT (end))
      {
--- 3732,3744 ----
    CHECK_NUMBER_COERCE_MARKER (end);
  
    if (XINT (beg) == XINT (end) && ! NILP (Foverlay_get (overlay, Qevaporate)))
!     return
! #ifndef OVERLAY_EVAPORATE_TESTING
!       Fdelete_overlay
! #else
!       evaporate_overlay
! #endif
!       (overlay);
  
    if (XINT (beg) > XINT (end))
      {
***************
*** 4088,4094 ****
        if (EQ (prop, Qevaporate) && ! NILP (value)
  	  && (OVERLAY_POSITION (OVERLAY_START (overlay))
  	      == OVERLAY_POSITION (OVERLAY_END (overlay))))
! 	Fdelete_overlay (overlay);
      }
    return value;
  }
--- 4122,4134 ----
        if (EQ (prop, Qevaporate) && ! NILP (value)
  	  && (OVERLAY_POSITION (OVERLAY_START (overlay))
  	      == OVERLAY_POSITION (OVERLAY_END (overlay))))
! #ifndef OVERLAY_EVAPORATE_TESTING
! 	Fdelete_overlay
! #else
!         evaporate_overlay
! #endif
!           (overlay);
! 
      }
    return value;
  }
***************
*** 4330,4336 ****
  	  hit_list = Fcons (overlay, hit_list);
        }
    for (; CONSP (hit_list); hit_list = XCDR (hit_list))
!     Fdelete_overlay (XCAR (hit_list));
  }
  \f
  /* Somebody has tried to store a value with an unacceptable type
--- 4370,4381 ----
  	  hit_list = Fcons (overlay, hit_list);
        }
    for (; CONSP (hit_list); hit_list = XCDR (hit_list))
! #ifndef OVERLAY_EVAPORATE_TESTING
!     Fdelete_overlay
! #else
!     evaporate_overlay
! #endif
!       (XCAR (hit_list));
  }
  \f
  /* Somebody has tried to store a value with an unacceptable type
***************
*** 5207,5212 ****
--- 5252,5261 ----
    staticpro (&Qoverlayp);
    Qevaporate = intern ("evaporate");
    staticpro (&Qevaporate);
+ #ifdef OVERLAY_EVAPORATE_TESTING
+   Qnever_set = intern ("never-set");
+   staticpro (&Qnever_set);
+ #endif
    Qmodification_hooks = intern ("modification-hooks");
    staticpro (&Qmodification_hooks);
    Qinsert_in_front_hooks = intern ("insert-in-front-hooks");

Re: Should overlays evaporate by default?

[Richard Stallman]

Thanks for writing this patch.  Now someone can run it
so as to look for code that ought to set evaporate properties.

Re: Should overlays evaporate by default?

[Peter Whaite]

Thien-Thi Nguyen <ttn@gnu.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
> 
> > The goal now is to *find* possible bugs.
> > The patch should set the property to something unusual (maybe
> > `never-set') by default.  When such an overlay becomes empty, there
> > should be some sort of warning.  That way, people will find code
> > that perhaps ought to set the evaporate property to something
> > explicitly.
> 
> ok, below is a patch to buffer.c that does this, more or less.  the
> (%d,%d) is perhaps redundant, but since we're in the checking mood...

Thanks that looks great.  Its a long weekend here, so I'll try it next
week.

-- 
Peter Whaite

Re: Should overlays evaporate by default? Conclusion: No!

[Peter Whaite]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

Thien-Thi Nguyen <ttn@gnu.org> wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> > The goal now is to *find* possible bugs.  The patch should set the
> > property to something unusual (maybe `never-set') by default.  When
> > such an overlay becomes empty, there should be some sort of warning.
> > That way, people will find code that perhaps ought to set the
> > evaporate property to something explicitly.
> 
> ok, below is a patch to buffer.c that does this, more or less.  the
> (%d,%d) is perhaps redundant, but since we're in the checking mood...

Thanks Thi.  I had to make a couple of changes (see below), but I have
been running with it for a few days now.

>From what I've seen I do not think it would be a good idea to change the
default.

The main reason is that there is a third, and common, use case which I
had not thought of.  This is where an overlay is used dynamically to
respond to user input, e.g. mouse.el, hl-line.el, comint, ediff, etc.
Typically a global or buffer local variable is used to hold the overlay,
which is positioned dynamically by applying move-overlay in response to
user input.  The positioning can result in the overlay becoming of zero
length.  Obviously it should not evaporate.

I did start to patch files exposed by my limited testing (see below),
but there were many, and I found I was setting 'evaporate to nil, not t.
Given that, and given that magically disappearing is in general
surprising default behaviour, then it would be better to retain the
current overlay defaults.

There remains the question of how to prevent overlay leaks.  It would
help if the elisp overlay documentation outlined the problem and
remedies ((overlay-put ovl 'evaporate t) or (remove-overlays)).  Perhaps
my original suggestion that erase-buffer also remove-overlays should be
considered.

For the record I'm attaching the patches I made to the elisp files.  A
quick grep through the lisp directory reveals many more that would need
patching.


[-- Attachment #2: evaporate-el.patch --]
[-- Type: text/plain, Size: 5150 bytes --]

Index: comint.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/comint.el,v
retrieving revision 1.319
diff -u -r1.319 comint.el
--- comint.el	26 May 2005 12:39:32 -0000	1.319
+++ comint.el	27 May 2005 17:05:46 -0000
@@ -1748,6 +1748,7 @@
 		  ;; Need to create the overlay
 		  (setq comint-last-prompt-overlay
 			(make-overlay prompt-start (point)))
+		  (overlay-put comint-last-prompt-overlay 'evaporate nil)
 		  (overlay-put comint-last-prompt-overlay
 			       'font-lock-face 'comint-highlight-prompt))))
 
Index: compare-w.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/compare-w.el,v
retrieving revision 1.26
diff -u -r1.26 compare-w.el
--- compare-w.el	28 Nov 2004 07:56:01 -0000	1.26
+++ compare-w.el	27 May 2005 17:05:46 -0000
@@ -341,12 +341,14 @@
     (if compare-windows-overlay1
         (move-overlay compare-windows-overlay1 beg1 end1 b1)
       (setq compare-windows-overlay1 (make-overlay beg1 end1 b1))
+      (overlay-put compare-windows-overlay1 'evaporate 'nil)
       (overlay-put compare-windows-overlay1 'face 'compare-windows-face)
       (overlay-put compare-windows-overlay1 'priority 1))
     (overlay-put compare-windows-overlay1 'window w1)
     (if compare-windows-overlay2
         (move-overlay compare-windows-overlay2 beg2 end2 b2)
       (setq compare-windows-overlay2 (make-overlay beg2 end2 b2))
+      (overlay-put compare-windows-overlay2 'evaporate 'nil)
       (overlay-put compare-windows-overlay2 'face 'compare-windows-face)
       (overlay-put compare-windows-overlay2 'priority 1))
     (overlay-put compare-windows-overlay2 'window w2)
Index: hl-line.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/hl-line.el,v
retrieving revision 1.28
diff -u -r1.28 hl-line.el
--- hl-line.el	4 Apr 2005 08:57:54 -0000	1.28
+++ hl-line.el	27 May 2005 17:05:46 -0000
@@ -134,6 +134,7 @@
       (progn
         (unless hl-line-overlay
           (setq hl-line-overlay (make-overlay 1 1)) ; to be moved
+	  (overlay-put hl-line-overlay 'evaporate nil)
           (overlay-put hl-line-overlay 'face hl-line-face))
         (overlay-put hl-line-overlay
                      'window (unless hl-line-sticky-flag (selected-window)))
@@ -168,6 +169,7 @@
     (unless (window-minibuffer-p (selected-window))
       (unless global-hl-line-overlay
         (setq global-hl-line-overlay (make-overlay 1 1)) ; to be moved
+	(overlay-put global-hl-line-overlay 'evaporate nil)
         (overlay-put global-hl-line-overlay 'face hl-line-face))
       (overlay-put global-hl-line-overlay 'window (selected-window))
       (hl-line-move global-hl-line-overlay))))
Index: image.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/image.el,v
retrieving revision 1.46
diff -u -r1.46 image.el
--- image.el	27 May 2005 13:17:50 -0000	1.46
+++ image.el	27 May 2005 17:05:46 -0000
@@ -170,6 +170,7 @@
     (let ((overlay (make-overlay pos pos buffer))
 	  (prop (if (null area) image (list (list 'margin area) image))))
       (put-text-property 0 (length string) 'display prop string)
+      (overlay-put overlay 'evaporate nil)
       (overlay-put overlay 'put-image t)
       (overlay-put overlay 'before-string string))))
 
Index: minibuf-eldef.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/minibuf-eldef.el,v
retrieving revision 1.6
diff -u -r1.6 minibuf-eldef.el
--- minibuf-eldef.el	2 Jun 2004 22:43:42 -0000	1.6
+++ minibuf-eldef.el	27 May 2005 17:05:46 -0000
@@ -98,6 +98,7 @@
       (setq match (if (consp match) (cdr match) 0))
       (setq minibuf-eldef-overlay
 	    (make-overlay (match-beginning match) (match-end match)))
+      (overlay-put minibuf-eldef-overlay 'evaporate nil)
       (setq minibuf-eldef-showing-default-in-prompt t)
       (setq minibuf-eldef-initial-input
 	    (minibuffer-contents-no-properties))
Index: mouse.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mouse.el,v
retrieving revision 1.271
diff -u -r1.271 mouse.el
--- mouse.el	23 Apr 2005 16:40:55 -0000	1.271
+++ mouse.el	27 May 2005 17:06:04 -0000
@@ -748,6 +748,7 @@
 
 ;; Create an overlay and immediately delete it, to get "overlay in no buffer".
 (defvar mouse-drag-overlay (make-overlay 1 1))
+(overlay-put mouse-drag-overlay 'evaporate nil)
 (delete-overlay mouse-drag-overlay)
 (overlay-put mouse-drag-overlay 'face 'region)
 
Index: gnus/gnus-cite.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/gnus-cite.el,v
retrieving revision 1.16
diff -u -r1.16 gnus-cite.el
--- gnus/gnus-cite.el	26 May 2005 15:03:29 -0000	1.16
+++ gnus/gnus-cite.el	27 May 2005 17:06:04 -0000
@@ -1017,6 +1017,7 @@
 	(when (< from to)
 	  (push (setq overlay (gnus-make-overlay from to))
 		gnus-cite-overlay-list)
+	  (gnus-overlay-put overlay 'evaporate t)
 	  (gnus-overlay-put overlay 'face face))))))
 
 (defun gnus-cite-toggle (prefix)

[-- Attachment #3: Type: text/plain, Size: 271 bytes --]


Also here is my version of Thi's patch to buffer.c.  I had to avoid
calling Foverlay_put from Fmake_overlay as it caused (make-overlay 1 1)
to immediately evaporate.  The only other change was to print more
information about the overlay so it was easier to track down.


[-- Attachment #4: evaporate.patch --]
[-- Type: text/plain, Size: 3123 bytes --]

Index: buffer.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/buffer.c,v
retrieving revision 1.480
diff -u -r1.480 buffer.c
--- buffer.c	27 May 2005 11:01:38 -0000	1.480
+++ buffer.c	27 May 2005 17:06:47 -0000
@@ -178,6 +178,12 @@
 Lisp_Object Qinsert_in_front_hooks;
 Lisp_Object Qinsert_behind_hooks;
 
+#define OVERLAY_EVAPORATE_TESTING
+#ifdef OVERLAY_EVAPORATE_TESTING
+Lisp_Object Qnever_set;
+static Lisp_Object evaporate_overlay P_ ((Lisp_Object));
+#endif
+
 static void alloc_buffer_text P_ ((struct buffer *, size_t));
 static void free_buffer_text P_ ((struct buffer *b));
 static struct Lisp_Overlay * copy_overlays P_ ((struct buffer *, struct Lisp_Overlay *));
@@ -3602,6 +3608,11 @@
   XOVERLAY (overlay)->plist = Qnil;
   XOVERLAY (overlay)->next = NULL;
 
+#ifdef OVERLAY_EVAPORATE_TESTING
+  XOVERLAY (overlay)->plist
+    = Fcons (Qevaporate, Fcons (Qnever_set, XOVERLAY (overlay)->plist));
+#endif
+
   /* Put the new overlay on the wrong list.  */
   end = OVERLAY_END (overlay);
   if (OVERLAY_POSITION (end) < b->overlay_center)
@@ -3656,6 +3667,24 @@
 \f
 Lisp_Object Fdelete_overlay ();
 
+#ifdef OVERLAY_EVAPORATE_TESTING
+static Lisp_Object
+evaporate_overlay (overlay)
+     Lisp_Object overlay;
+{
+  if (EQ (Qnever_set, Foverlay_get (overlay, Qevaporate)))
+    {
+	Lisp_Object args[3];
+	args[0] = build_string("WARNING: Evaporating %S %S");
+	args[1] = overlay;
+	args[2] = Foverlay_properties(overlay);
+	Fmessage(3,args);
+    }
+
+  return Fdelete_overlay (overlay);
+}
+#endif
+
 static struct Lisp_Overlay *
 unchain_overlay (list, overlay)
      struct Lisp_Overlay *list, *overlay;
@@ -3704,7 +3733,13 @@
   CHECK_NUMBER_COERCE_MARKER (end);
 
   if (XINT (beg) == XINT (end) && ! NILP (Foverlay_get (overlay, Qevaporate)))
-    return Fdelete_overlay (overlay);
+    return
+#ifndef OVERLAY_EVAPORATE_TESTING
+      Fdelete_overlay
+#else
+      evaporate_overlay
+#endif
+      (overlay);
 
   if (XINT (beg) > XINT (end))
     {
@@ -4088,7 +4123,13 @@
       if (EQ (prop, Qevaporate) && ! NILP (value)
 	  && (OVERLAY_POSITION (OVERLAY_START (overlay))
 	      == OVERLAY_POSITION (OVERLAY_END (overlay))))
-	Fdelete_overlay (overlay);
+#ifndef OVERLAY_EVAPORATE_TESTING
+	Fdelete_overlay
+#else
+        evaporate_overlay
+#endif
+          (overlay);
+
     }
   return value;
 }
@@ -4330,7 +4371,12 @@
 	  hit_list = Fcons (overlay, hit_list);
       }
   for (; CONSP (hit_list); hit_list = XCDR (hit_list))
-    Fdelete_overlay (XCAR (hit_list));
+#ifndef OVERLAY_EVAPORATE_TESTING
+    Fdelete_overlay
+#else
+    evaporate_overlay
+#endif
+      (XCAR (hit_list));
 }
 \f
 /* Somebody has tried to store a value with an unacceptable type
@@ -5207,6 +5253,10 @@
   staticpro (&Qoverlayp);
   Qevaporate = intern ("evaporate");
   staticpro (&Qevaporate);
+#ifdef OVERLAY_EVAPORATE_TESTING
+  Qnever_set = intern ("never-set");
+  staticpro (&Qnever_set);
+#endif
   Qmodification_hooks = intern ("modification-hooks");
   staticpro (&Qmodification_hooks);
   Qinsert_in_front_hooks = intern ("insert-in-front-hooks");

[-- Attachment #5: Type: text/plain, Size: 17 bytes --]


--
Peter Whaite

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Should overlays evaporate by default? Conclusion: No!

[Richard Stallman]

    I did start to patch files exposed by my limited testing (see below),
    but there were many, and I found I was setting 'evaporate to nil, not t.
    Given that, and given that magically disappearing is in general
    surprising default behaviour, then it would be better to retain the
    current overlay defaults.

Ok.  Thanks for testing this.

Did you find any cases where the code ought to put on t as the
evaporate property?  Your patches include one, in gnus-cite.  Were
there others?

Re: Should overlays evaporate by default? Conclusion: No!

[Peter Whaite]

Richard Stallman <rms@gnu.org> wrote:
>
> Did you find any cases where the code ought to put on t as the
> evaporate property?  Your patches include one, in gnus-cite.  Were
> there others?

No but I didn't look very far.  I only picked up gnus-cite because its
used by mh-e.

I'll continue running with the patch, and I will let you know if I see
more.

---
Peter Whaite

Re: Should overlays evaporate by default? Conclusion: No!

[Richard Stallman]

    I'll continue running with the patch, and I will let you know if I see
    more.

Thanks.  Every such case you find this way
is one long debugging session saved.

Re: RMAIL slows

[Robert J. Chassell]

[I just sent a message saying I first had 

    (add-hook 'rmail-show-message-hook 'goto-address)

in my .emacs file.  I got many overlapping overlays.  Then I commented
that line out and started a new instance of Emacs.  I got only two
overlays, neither overlapping.]

Now I have uncommented the line and started yet a newer instance of
Emacs. So I add the hook again.  On doing this for the same RMAIL file
as before on the same message:

        (pp
         (save-restriction
           (widen)
           (overlays-in (point-min)
                        (point-max)))
         (get-buffer-create "*overlays*"))

I see the following:

(#<overlay from 1150322 to 1150363 in RMAIL> #<overlay from 1150338 to 1150362 in RMAIL> #<overlay from 1150300 to 1150315 in RMAIL> #<overlay from 1150271 to 1150290 in RMAIL> #<overlay from 1150250 to 1150268 in RMAIL> #<overlay from 1150211 to 1150230 in RMAIL>)

Two overlays overlap:


#<overlay from 1150322 to 1150363 in RMAIL> 
#<overlay from 1150338 to 1150362 in RMAIL>

For this, the overlay properties for `nth 0' are

    (face bold)

but for `nth 1' are

    (goto-address t keymap
                  (keymap
                   (3 keymap
                      (13 . goto-address-at-point))
                   (mouse-2 . goto-address-at-mouse))
                  help-echo "mouse-2, C-c RET: mail this address" mouse-face secondary-selection face italic)

For `nth 2' they are

    (face bold)

again.

Hope this helps!

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

	(length (save-restriction (widen) (overlays-in (point-min) (point-max))))

       to see how many overlays are in the buffer?

    6128

Please look at the value of rmail-overlay-list.
Are most of these overlays in that list?

Re: RMAIL slows

[Robert J. Chassell]

With an even newer instance of Emacs and the `goto-address' hook
commented out

        (pp
         (save-restriction
           (widen)
           (overlays-in (point-min)
                        (point-max)))
         (get-buffer-create "*overlays*"))

tells me

    (#<overlay from 1203430 to 1203445 in RMAIL> 
     #<overlay from 1203316 to 1203346 in RMAIL> 
     #<overlay from 1148200 to 1148200 in RMAIL>)

But rmail-overlay-list's value is 

    (#<overlay from 1203316 to 1203346 in RMAIL> 
     #<overlay from 1203430 to 1203445 in RMAIL>)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RMAIL slows

[Richard Stallman]

    I put a breakpoint in `adjust_markers_for_delete' and looped at least 8
    times.

Well, this suggests it is a matter of the number of markers.
I suggest you look at the chain of markers

      for (m = BUF_MARKERS (current_buffer); m; m = m->next)

and see how long it is.  (You could do that by setting a breakpoint
in the loop that silently executes a command such as
  set $count++
and setting $count to 0 before the loop.  At the end of the loop
you can examine $count.)

If the problem is due to an accumulation of markers, the question is
why.  The markers clearly are not dead, or they'd be GC'd.  They must
be used in some data structure.  If you can determine what structure,
we could fix this.

Maybe the only way to find it is to look thru rmail to see what makes
markers and puts them into data structures.

SPC in custom-mode

[Lennart Borgman]

SPC in custom buffers currently always scrolls the buffer. I do not 
think this is the expected behaviour by most users.

A common use of SPC (web browsers, w32 programs) is to "push the button" 
when keyboard focus is on the button. I think that would be better - at 
least when focus is on a button.

Re: SPC in custom-mode

[Per Abrahamsen]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> SPC in custom buffers currently always scrolls the buffer. I do not 
> think this is the expected behaviour by most users.
>
> A common use of SPC (web browsers, w32 programs) is to "push the button" 
> when keyboard focus is on the button. I think that would be better - at 
> least when focus is on a button.

I believe the choice of bindings was made to mimic info mode.  If the
binding is changed in customize, info mode should also be changed.

Re: SPC in custom-mode

[Lennart Borgman]

Per Abrahamsen wrote:

>Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>  
>
>>SPC in custom buffers currently always scrolls the buffer. I do not 
>>think this is the expected behaviour by most users.
>>
>>A common use of SPC (web browsers, w32 programs) is to "push the button" 
>>when keyboard focus is on the button. I think that would be better - at 
>>least when focus is on a button.
>>    
>>
>
>I believe the choice of bindings was made to mimic info mode.  If the
>binding is changed in customize, info mode should also be changed.
>
Thanks, but there are no buttons to push in Info? Perhaps it could be 
changed only when focus is on a button.

Re: SPC in custom-mode

[Per Abrahamsen]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Per Abrahamsen wrote:
> Thanks, but there are no buttons to push in Info? 

There are plenty.  All the cross references and menu buttons.

Re: SPC in custom-mode

[Peter Whaite]

> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
> > SPC in custom buffers currently always scrolls the buffer. I do not 
> > think this is the expected behaviour by most users.

And BSPC scrolls it backwards just like 'less', which is what I expect,
and what I like.

> > A common use of SPC (web browsers, w32 programs) is to "push the button" 
> > when keyboard focus is on the button. I think that would be better - at 
> > least when focus is on a button.

Thats in dialogs (not browser windows e.g.), and there I always use ENTER for
pushing buttons.  I do that in custom buffers too.

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> I believe the choice of bindings was made to mimic info mode.  If the
> binding is changed in customize, info mode should also be changed.

Perhaps info mode was made to mimic less :-).
 
Must we always go the windows gui route?  Being able to use the left
mouse to push buttons is a good change, but I prefer to retain the unixy
less-like behaviour for scrolling around in read only buffers.


-- 
Peter Whaite

Re: SPC in custom-mode

[Lennart Borgman]

Peter Whaite wrote:

>>>A common use of SPC (web browsers, w32 programs) is to "push the button" 
>>>when keyboard focus is on the button. I think that would be better - at 
>>>least when focus is on a button.
>>>      
>>>
>
>Thats in dialogs (not browser windows e.g.), and there I always use ENTER for
>pushing buttons.  I do that in custom buffers too.
>  
>
I just tested Firefox. SPC scrolls forward and S-SPC backward - unless 
you are on a button (like a normal button, checkbox or radiobutton). In 
that case SPC "clicks" the button.

>Perhaps info mode was made to mimic less :-).
>  
>
I did use less for a long time until I found a good editor...

> 
>Must we always go the windows gui route?  Being able to use the left
>mouse to push buttons is a good change, but I prefer to retain the unixy
>less-like behaviour for scrolling around in read only buffers.
>  
>
Firefox decided do as less for SPC but not for BSPC as far as I 
understand. I like the ability to be able to scroll forward with SPC. 
The only thing I am suggesting is that this behaviour should perhaps be 
changed when point is on a button. However this is by no means a big thing.

Re: SPC in custom-mode

[Peter Whaite]

Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
> I just tested Firefox. SPC scrolls forward and S-SPC backward - unless you are
> on a button (like a normal button, checkbox or radiobutton). In that case SPC
> "clicks" the button.

Details, details :-), but you're right -- thats what it does.

I guess that means on pages where there are no links, and in which there
is nothing but controls, you can't use SPC to scroll.

> I like the ability to be able to scroll forward with SPC. The only
> thing I am suggesting is that this behaviour should perhaps be changed
> when point is on a button. However this is by no means a big thing.

I dont think it should be changed.  Custom buffers are essentially a
long form containing only buttons.  In order to SPC scroll you would
have to move point off the button, and that sounds very inconvenient.

Why not just keep it simple.  SPC scrolls.  ENTER activates.

-- 
Peter Whaite

Re: SPC in custom-mode

[Lennart Borgman]

Peter Whaite wrote:

>Why not just keep it simple.  SPC scrolls.  ENTER activates.
>  
>
Because I have several times pressed SPC instead of ENTER. I guess I 
will not be the only one - or I hope I will not be the only one. It is 
quite confusing and unexpected that the buffer scrolls in this situation.

But there are more important things to consider at the moment of course.

Re: SPC in custom-mode

[Mathias Dahl]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

>>Why not just keep it simple.  SPC scrolls.  ENTER activates.
>>  
>>
> Because I have several times pressed SPC instead of ENTER. I guess I
> will not be the only one - or I hope I will not be the only one. It is
> quite confusing and unexpected that the buffer scrolls in this
> situation.

I have been using Windows in different forms since back in 1990 and I
probably know more about all keyboard shortcuts in Windows than most
people do. I too use SPC to activate raised/marked buttons but also
RET sometimes.

I would say that if I had to choose which of SPC and RET (or ENTER if
you want, although those are different keys in Emacs) that would
activate a button, RET would be the most probable one.

Maybe I have just been using Emacs for too long now...

Re: SPC in custom-mode

[Joakim Verona]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Peter Whaite wrote:
>
>>Why not just keep it simple.  SPC scrolls.  ENTER activates.
>>  

I think its much more important that Emacs is consistent within itself
than that Emacs is consistent with some random gui.

So I think:

- Custom and Info should be more alike than they are today.
- Eshell and Shell mode should be more alike as well.

And other random things:

- comment-region should always be bound to the same key

And so on. There are many such discrepancies in Emacs.


If some windows users want emacs to be more windows-gui consistent on
their plattform, cant these changes go into Cua mode or something?

One of the bad things with Windows is that MS changes the GUI now and
then, for no apparent benefit. Key-bindings, for instance, change with
the language you have installed A Windows app with.

On the other hand, C-x C-f will always find a file in emacs, which is
a great benefit.



> Because I have several times pressed SPC instead of ENTER. I guess I 
> will not be the only one - or I hope I will not be the only one. It is 
> quite confusing and unexpected that the buffer scrolls in this situation.
>
> But there are more important things to consider at the moment of course.

-- 
Joakim Verona
www.verona.se

Re: SPC in custom-mode

[Richard M. Stallman]

    Must we always go the windows gui route?  Being able to use the left
    mouse to push buttons is a good change, but I prefer to retain the unixy
    less-like behaviour for scrolling around in read only buffers.

I agree with you.  There is no reason to make SPC "push buttons" in Emacs.
People, let's please drop that idea.

The amount of discussion going on now is distracting.  Even ignoring
the Windows-specific and Mac-specific issues, I can't read it all.
Please don't raise any more issues now.

fancy-splash-screen customize group...

[David Kastrup]

Hi,
when doing
M-x customize-group RET fancy-splash-screen RET

I actually don't get a customizable option for the most important
thing: how to turn it off.

I consider that an omission.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    M-x customize-group RET fancy-splash-screen RET

    I actually don't get a customizable option for the most important
    thing: how to turn it off.

Precisely what do you want to turn off?

Re: fancy-splash-screen customize group...

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     M-x customize-group RET fancy-splash-screen RET
>
>     I actually don't get a customizable option for the most important
>     thing: how to turn it off.
>
> Precisely what do you want to turn off?

A splash screen at startup.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    > Precisely what do you want to turn off?

    A splash screen at startup.

That is done by inhibit-startup-message, which is in the group
initialization.

That is the parent of the fancy-splash-screen group.  So I think it
would have been easy enough to find this if you looked a little
harder.

Re: fancy-splash-screen customize group...

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > Precisely what do you want to turn off?
>
>     A splash screen at startup.
>
> That is done by inhibit-startup-message, which is in the group
> initialization.
>
> That is the parent of the fancy-splash-screen group.  So I think it
> would have been easy enough to find this if you looked a little
> harder.

The description in the documentation, the name, and also related
options don't suggest a connection.  I looked there, but did not make
the connection.

You might validly consider me stupid, but I guess that my level of
stupidity would be common enough to warrant catering for.

As long as catering for the stupid does not mean hampering the
intelligent people, it will save questions and annoyance.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: fancy-splash-screen customize group...

[Stefan Monnier]

>> Precisely what do you want to turn off?
>     A splash screen at startup.
> That is done by inhibit-startup-message, which is in the group
> initialization.

Except that nowhere is it made clear that inhibit-startup-message has
something to do with the splash screen.


        Stefan

Re: fancy-splash-screen customize group...

[Romain Francoise]

David Kastrup <dak@gnu.org> writes:

> when doing
> M-x customize-group RET fancy-splash-screen RET

> I actually don't get a customizable option for the most important
> thing: how to turn it off.

That's because the relevant option is in the `initialization' group.
We can add it also to the `fancy-splash-screen' group, but it uses a
different terminology ("startup message" vs. "fancy splash screen").

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: fancy-splash-screen customize group...

[David Kastrup]

Romain Francoise <romain@orebokech.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> when doing
>> M-x customize-group RET fancy-splash-screen RET
>
>> I actually don't get a customizable option for the most important
>> thing: how to turn it off.
>
> That's because the relevant option is in the `initialization' group.
> We can add it also to the `fancy-splash-screen' group, but it uses a
> different terminology ("startup message" vs. "fancy splash screen").

Well, I actually went to the `initialization' group, but did not
associate "inhibit startup message" (and the message is later spelled
out as text in the group) with the fancy splash screen.

Call me stupid, but it would be my bet that enough coidiots may be
found as to make it worthwhile making this more explicit.

Maybe the doc for inhibit startup message should be the point
explaining this?  If it does, then replicating the option in the fancy
splash screen group might look less out of kilter.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: fancy-splash-screen customize group...

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

>>> when doing
>>> M-x customize-group RET fancy-splash-screen RET
>>
>>> I actually don't get a customizable option for the most important
>>> thing: how to turn it off.
>>
>> That's because the relevant option is in the `initialization' group.
>> We can add it also to the `fancy-splash-screen' group, but it uses a
>> different terminology ("startup message" vs. "fancy splash screen").
>
> Well, I actually went to the `initialization' group, but did not
> associate "inhibit startup message" (and the message is later spelled
> out as text in the group) with the fancy splash screen.

M-x apropos RET splash screen RET

  display-splash-screen
    Command: Display splash screen according to display.
  fancy-splash-screen
    Group: Fancy splash screen when Emacs starts.
    Plist: group-documentation custom-version custom-group
  fancy-splash-screens
    Function: Display fancy splash screens when Emacs starts.
  fancy-splash-screens-1
    Function: Timer function displaying a splash screen.
  inhibit-splash-screen
    Variable: (not documented)


inhibit-splash-screen is a variable defined in `startup.el'.
Its value is t

This variable is an alias for `inhibit-startup-message'.
Documentation:
*Non-nil inhibits the initial startup message.
This is for use in your personal init file, once you are familiar
with the contents of the startup message.

Re: fancy-splash-screen customize group...

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Well, I actually went to the `initialization' group, but did not
>> associate "inhibit startup message" (and the message is later spelled
>> out as text in the group) with the fancy splash screen.
>
> M-x apropos RET splash screen RET

It may be a good idea to add a button to Customize buffers, labelled
"Find option...", that calls apropos-variable.

RE: fancy-splash-screen customize group...

[Drew Adams]

    It may be a good idea to add a button to Customize buffers, labelled
    "Find option...", that calls apropos-variable.

Good idea - or at least a menu item (haven't looked - maybe there is one
already?). There are already quite a few buttons...

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

	It may be a good idea to add a button to Customize buffers, labelled
	"Find option...", that calls apropos-variable.

    Good idea - or at least a menu item (haven't looked - maybe there is one
    already?). There are already quite a few buttons...

I think this would only be marginally useful, not enough to justify
the added complexity, so my decision is not to add it.

Please don't make suggestions for new features of marginal utility.
We need to fix bugs.

Re: fancy-splash-screen customize group...

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

> 	It may be a good idea to add a button to Customize buffers, labelled
> 	"Find option...", that calls apropos-variable.
>
>     Good idea - or at least a menu item (haven't looked - maybe there is one
>     already?). There are already quite a few buttons...
>
> I think this would only be marginally useful, not enough to justify
> the added complexity, so my decision is not to add it.

In my experience, the biggest problem with Customize is that it is
very difficult to find a user option, because of the sheer number of
customization groups and options.  That's the main problem I had back
when I was learning to use Emacs.  In fact, I found it easier to learn
Emacs Lisp and write a .emacs file than to use Customize.

As for additional complexity, I implemented the idea for my own
personal amusement, and it was easy.

Re: fancy-splash-screen customize group...

[Peter Whaite]

Chong Yidong <cyd@stupidchicken.com> wrote:
> 
> In my experience, the biggest problem with Customize is that it is
> very difficult to find a user option, because of the sheer number of
> customization groups and options.

I agree, but customize-apropos is a big help.

-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Xavier Maillard]

   From: Chong Yidong <cyd@stupidchicken.com>
   In my experience, the biggest problem with Customize is that it is
   very difficult to find a user option, because of the sheer number of
   customization groups and options.  That's the main problem I had back
   when I was learning to use Emacs.  In fact, I found it easier to learn
   Emacs Lisp and write a .emacs file than to use Customize.

I second that even if with the help of apropos and describe-* functions, 
customize is much more simpler to master.

I still prefer using Emacs lisp code directly in my .emacs though.

Xavier

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

       In my experience, the biggest problem with Customize is that it is
       very difficult to find a user option, because of the sheer number of
       customization groups and options.

If it is simply due to the number of options that exist, I don't
suppose anything can be done to improve that.  We're not going to
get rid of a large fraction of the options.

If someone has other ideas to make it easier to navigate thru Custom,
we could entertain them.

Have you tried M-x customize-browse?

Re: fancy-splash-screen customize group...

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>        In my experience, the biggest problem with Customize is that it is
>        very difficult to find a user option, because of the sheer number of
>        customization groups and options.
>
> If it is simply due to the number of options that exist, I don't
> suppose anything can be done to improve that.  We're not going to
> get rid of a large fraction of the options.

That's the point of linking Customize to apropos, so that you can
search for the option you want.

Re: fancy-splash-screen customize group...

[Peter Whaite]

Chong Yidong <cyd@stupidchicken.com> wrote:

> That's the point of linking Customize to apropos, so that you can
> search for the option you want.

I seem to have missed much of this discussion, but when I first ran
across the customize beast I wished there was a 'Search' field or button
in the customize buffer.  Now that I know about the customize-apropos
functions I dont wish so much, but it would still be useful for
newcomers.

At the very least the text at the top of the customize buffers should
mention the apropos functions.

You would also expect something about finding customizations to be in
the info that is displayed when you press the 'Help' button, but there
is nothing obvious.  The documentation for 'customize-apropos' is under
'Specific Customization' which doesn't exactly jump out at you.  How
about renaming it to 'Finding Customizations', and changing the info
node header to 'Finding and Customizing Specific Items'?

There is also no mention of customize-apropos-options,
customize-apropos-groups, or customize-apropos-faces.  There should be.

-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Peter Whaite wrote:

>You would also expect something about finding customizations to be in
>the info that is displayed when you press the 'Help' button, but there
>is nothing obvious.  The documentation for 'customize-apropos' is under
>'Specific Customization' which doesn't exactly jump out at you.  How
>about renaming it to 'Finding Customizations', and changing the info
>node header to 'Finding and Customizing Specific Items'?
>
>There is also no mention of customize-apropos-options,
>customize-apropos-groups, or customize-apropos-faces.  There should be.
>  
>
I have already once proposed and written a new look and feel for the 
custom buffer. Now is not the time to do that perhaps (and my old patch 
will not work now), but some simple things can be done now to make the 
situation a bit better:

*** 1) At the top of the customize buffer there are now two buttons that 
does not work on the content of the buffer at all. These are

    Invoke [Custom File] for information...
    Invoke [Help] for general information.

Changing the look of this buttons to just underlined text would improve 
things a lot. They are really just links. Changing "Invoke" to "See" 
would make it less of a guessing game too.


*** 2) When you click on the "Help" link (button) then the info node 
"(emacs) Easy Customization" is displayed. I believe the 
customize-apropos-* functions should be mentioned there, right after 
"Groups" in the menu at the bottom.

Re: fancy-splash-screen customize group...

[Chong Yidong]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Changing the look of this buttons to just underlined text would
> improve things a lot.

Setting `custom-raised-buttons' to nil probably does what you want.

Re: fancy-splash-screen customize group...

[Jason Rumney]

Chong Yidong <cyd@stupidchicken.com> writes:

> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>> Changing the look of this buttons to just underlined text would
>> improve things a lot.
>
> Setting `custom-raised-buttons' to nil probably does what you want.

I don't think so. What Lennart is suggesting is to change the look of
those two links, so they are not confused with the other buttons which
all perform some action on the custom buffer.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Jason Rumney wrote:

   I don't think so. What Lennart is suggesting is to change the look of
   those two links, so they are not confused with the other buttons which
   all perform some action on the custom buffer.

No, Custom buffers contain several other buttons that follow links to
manuals and other places.  It would be inconsistent to change the look
of these two buttons only.  All link type widgets should look the same
and right now, they look like buttons.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Luc Teirlinck wrote:

>Jason Rumney wrote:
>
>   I don't think so. What Lennart is suggesting is to change the look of
>   those two links, so they are not confused with the other buttons which
>   all perform some action on the custom buffer.
>
>No, Custom buffers contain several other buttons that follow links to
>manuals and other places.  It would be inconsistent to change the look
>of these two buttons only.  All link type widgets should look the same
>and right now, they look like buttons.
>  
>
You are right, I forgot those. Of course I mean that those should be 
changed too. Is not that easy enough to do now?

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Lennart Borgman wrote:

   You are right, I forgot those. Of course I mean that those should be 
   changed too. Is not that easy enough to do now?

I did not look at it in depth, but at first view it does not look that
trivial.  You would have to make the :link widget type more different
from other widget types, thereby making the widget library less
homogeneous and, I would guess, thereby more complex (as if it were not
already complicated enough).

What you point out does not seem to be such a terrible problem.  If
you see:

  Invoke Custom file for information on how to save in a different file.
  Invoke Help for general information.

with "Custom" and "Help" being raised buttons, what else would you
expect clicking on these buttons to do than follow links to documentation?

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Luc Teirlinck wrote:

>Lennart Borgman wrote:
>
>   You are right, I forgot those. Of course I mean that those should be 
>   changed too. Is not that easy enough to do now?
>
>I did not look at it in depth, but at first view it does not look that
>trivial.  You would have to make the :link widget type more different
>from other widget types, thereby making the widget library less
>homogeneous and, I would guess, thereby more complex (as if it were not
>already complicated enough).
>
I do not think it will make things more complicated. This is what I am 
currently using for doing similar things:

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
(defface emacsw32-link-face
  `((((class color) (background light)) (:foreground "blue" :underline t))
    (((class color) (background dark)) (:foreground "cyan" :underline t)))
  "Face used to highlight attributes that are links."
  :group 'emacsw32)


(defun emacsw32-custom-url-link(txt url)
  (let ((plain-url (substring-no-properties url)))
    (unless (equal txt url)
      (put-text-property 0 (length txt) 'help-echo plain-url txt))
    (put-text-property 0 (length txt) 'mouse-face 'highlight txt)
    (let ((btn (widget-create
                'push-button
                :notify 'emacsw32-notify-btn-url
                :button-face 'emacsw32-link-face
                :button-prefix ""
                :button-suffix ""
                txt)))
      (widget-put btn 'url url))))
 
(defun emacsw32-notify-btn-url(widget &rest ignore)
  (browse-url (widget-get widget 'url)))

;;; Use it like this:

      (emacsw32-custom-url-link "GNU Home page" "http://www.gnu.org/")

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Changing this code a bit will do the trick I believe. No changes to 
basic functions are needed. Or am I wrong?

Re: fancy-splash-screen customize group...

[Xavier Maillard]

   From: Lennart Borgman <lennart.borgman.073@student.lu.se>
   Cc: rms@gnu.org, cyd@stupidchicken.com, emacs@whaite.ca,
           jasonr@gnu.org, zedek@gnu-rox.org, emacs-devel@gnu.org,
           drew.adams@oracle.com

   Luc Teirlinck wrote:

   I do not think it will make things more complicated. This is what I am 
   currently using for doing similar things:

   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

   Changing this code a bit will do the trick I believe. No changes to 
   basic functions are needed. Or am I wrong?

This is nice stuff and enough I guess.

Xavier

Re: fancy-splash-screen customize group...

[Peter Whaite]

Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
>
> with "Custom" and "Help" being raised buttons, what else would you
> expect clicking on these buttons to do than follow links to
> documentation?

Its not clear, because the second sentence says:

  `Raised' buttons show active fields; type RET or click mouse-1 on an
  active field to invoke its action.

and I dont know what an "active field" is, and I've no idea what its
action would be.  Yes I will click it and try because it looks like a
button.  That sentence should be deleted -- it contains no useful
information.

The line:

   Invoke Custom file for information on how to save in a different
   file.

should be deleted.  Its only of interest to expert users, and they can
find it easily in the Help.

"Invoke" is something a programmer would say.  It is much better to
write:

   See Help for more information.

It would be better if 'Help' were underlined to emphasize that its a
link.  People understand links and it looks better.  However it is not a
big deal if the widget library (of which I am ignorant) prevents it
being done easily.

With the changes I'm suggesting you end up with the following preamble:

  This is a customization buffer for group Emacs.
  
  Editing an option value changes only the text in the buffer.  The
  State button can be used to set or save the option value.  Saving an
  option normally edits your init file.

  See Help for more information.

I think thats a significant improvement, and its easy to do.


-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Juri Linkov]

> With the changes I'm suggesting you end up with the following preamble:
>
>   This is a customization buffer for group Emacs.
>
>   Editing an option value changes only the text in the buffer.  The
>   State button can be used to set or save the option value.  Saving an
>   option normally edits your init file.
>
>   See Help for more information.

I think your change makes this header more clear.  The only part that
is still confusing is

    The State button can be used to set or save the option value.

I suspect that the first thing that a novice will do after reading this
is to search the button with the name "State" in the customization buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: fancy-splash-screen customize group...

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

Juri Linkov wrote:

>>With the changes I'm suggesting you end up with the following preamble:
>>
>>  This is a customization buffer for group Emacs.
>>
>>  Editing an option value changes only the text in the buffer.  The
>>  State button can be used to set or save the option value.  Saving an
>>  option normally edits your init file.
>>
>>  See Help for more information.
>>    
>>
>
>I think your change makes this header more clear.  The only part that
>is still confusing is
>
>    The State button can be used to set or save the option value.
>
>I suspect that the first thing that a novice will do after reading this
>is to search the button with the name "State" in the customization buffer.
>  
>
I have attached a preliminary patch for this. The patch changes the text 
to something reminding of the text above. It also changes the links from 
a button-like style to underline. Please test the patch.

There is one thing that I have not found out how to change it: the 
"mouse over" face. It is gray whatever I do. If someone knows how to 
make a widget really display the highlight face then please tell me!

[-- Attachment #2: cus-edit-links.patch --]
[-- Type: text/plain, Size: 5263 bytes --]

Index: cus-edit.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.243
diff -c -r1.243 cus-edit.el
*** cus-edit.el	4 Dec 2005 02:39:24 -0000	1.243
--- cus-edit.el	7 Dec 2005 22:32:29 -0000
***************
*** 1412,1445 ****
  		   'custom-button-pressed
  		 'custom-button-pressed-unraised))))
  
  (defun custom-buffer-create-internal (options &optional description)
    (custom-mode)
    (if custom-buffer-verbose-help
!       (progn
  	(widget-insert "This is a customization buffer")
  	(if description
  	    (widget-insert description))
  	(widget-insert (format ".
! %s show active fields; type RET or click mouse-1
! on an active field to invoke its action.  Editing an option value
! changes only the text in the buffer.  Invoke the State button to set or
! save the option value.  Saving an option normally edits your init file.
! Invoke "
  			       (if custom-raised-buttons
  				   "`Raised' buttons"
  				 "Square brackets")))
  	(widget-create 'info-link
! 		       :tag "Custom file"
! 		       "(emacs)Saving Customizations")
! 	(widget-insert
! 	 " for information on how to save in a different file.
! Invoke ")
! 	(widget-create 'info-link
! 		       :tag "Help"
  		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for general information.\n\n")
! 	(widget-insert "Operate on everything in this buffer:\n "))
      (widget-insert " "))
    (widget-create 'push-button
  		 :tag "Set for Current Session"
--- 1412,1471 ----
  		   'custom-button-pressed
  		 'custom-button-pressed-unraised))))
  
+ (defface custom-link-face
+   `((((class color) (background light)) (:foreground "blue" :underline t))
+     (((class color) (background dark)) (:foreground "cyan" :underline t)))
+   "Face used to highlight attributes that are links."
+   :group 'custom-faces)
+ 
+ 
  (defun custom-buffer-create-internal (options &optional description)
    (custom-mode)
    (if custom-buffer-verbose-help
!       (let (
!             (custom-file-txt "custom file")
!             (help-txt "help"))
!         ;;(put-text-property 0 (length custom-file-txt) 'mouse-face 'highlight custom-file-txt)
!         ;;(put-text-property 0 (length help-txt) 'mouse-face 'highlight help-txt)
  	(widget-insert "This is a customization buffer")
  	(if description
  	    (widget-insert description))
+ ;; %s show active fields; type RET or click mouse-1
+ ;; on an active field to invoke its action.  Editing an option value
+ ;; changes only the text in the buffer.  Invoke the State button to set or
+ ;; save the option value.  Saving an option normally edits your init file.
  	(widget-insert (format ".
! 
! Editing an option value changes only the text in the buffer.  The
! State button(s) next to the option(s) can be used to set or save
! the value. Saving an option normally edits your init file.
! 
! See "
  			       (if custom-raised-buttons
  				   "`Raised' buttons"
  				 "Square brackets")))
+ ;; 	(widget-create 'info-link
+ ;;                        :button-face 'custom-link-face
+ ;;                        :button-prefix ""
+ ;;                        :button-suffix ""
+ ;; 		       ;;:tag "Custom file"
+ ;; 		       :tag custom-file-txt
+ ;; 		       "(emacs)Saving Customizations")
+ ;; 	(widget-insert
+ ;; 	 " for information on how to save in a different file.\n\nSee ")
+ 
  	(widget-create 'info-link
!                        :button-face 'custom-link-face
!                        :button-prefix ""
!                        :button-suffix ""
!                        :mouse-face 'highlight
!                        :button-mouse-face 'highlight
! 		       ;;:tag "Help"
! 		       :tag help-txt
  		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for more information.\n\n")
! 	(widget-insert "Operate on all options in this buffer:\n "))
      (widget-insert " "))
    (widget-create 'push-button
  		 :tag "Set for Current Session"
***************
*** 2149,2154 ****
--- 2175,2183 ----
  		  (insert " ")
  		  (push (widget-create-child-and-convert
  			 widget 'custom-group-link
+                          :button-face 'custom-link-face
+                          :button-prefix ""
+                          :button-suffix ""
  			 :tag (custom-unlispify-tag-name symbol)
  			 symbol)
  			buttons)
***************
*** 2160,2166 ****
             (when links
               (insert "\nParent documentation: ")
               (while links
!                (push (widget-create-child-and-convert widget (car links))
                       buttons)
                 (setq links (cdr links))
                 (cond ((null links)
--- 2189,2200 ----
             (when links
               (insert "\nParent documentation: ")
               (while links
!                (push (widget-create-child-and-convert
!                       widget (car links)
!                       :button-face 'custom-link-face
!                       :button-prefix ""
!                       :button-suffix ""
!                       )
                       buttons)
                 (setq links (cdr links))
                 (cond ((null links)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: fancy-splash-screen customize group...

[Peter Whaite]

Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> I have attached a preliminary patch for this. The patch changes the text to
> something reminding of the text above. It also changes the links from a
> button-like style to underline. Please test the patch.

 Great job -- that is much better! The only change I would make is to replace

   The State button(s) next to the option(s) can be used to set or save
   the value.

with

   The State buttons can be used to set or save option values.

because there are State buttons that are not next to options,
there is more than one state button, and the '(s)' thing is, in my
opinion, bad style.

> There is one thing that I have not found out how to change it: the "mouse
> over" face. It is gray whatever I do. If someone knows how to make a widget
> really display the highlight face then please tell me!

I see what you mean.  Sorry I don't have an answer, but I'll let you
know if I find one.


-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Peter Whaite wrote:

> Great job -- that is much better! The only change I would make is to replace
>
>   The State button(s) next to the option(s) can be used to set or save
>   the value.
>
>with
>
>   The State buttons can be used to set or save option values.
>
>because there are State buttons that are not next to options,
>there is more than one state button, and the '(s)' thing is, in my
>opinion, bad style.
>  
>
Thanks, but are there really state buttons that are not next to options? 
Is not both yours and mine sentence wrong then? Or can you give an 
example, please?

Re: fancy-splash-screen customize group...

[Peter Whaite]

Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
> Thanks, but are there really state buttons that are not next to options? Is
> not both yours and mine sentence wrong then? Or can you give an example,
> please?

At the top of every customize group page there is a global state button
that can be used to set or save all the options that have been changed
in the page, e.g.

/- Emacs group: ---------------------------------------------------------\
      State: visible group members are all at standard settings.
   Customization of the One True Editor.
   See also Manual.

No big deal, though I don't think its necessary to say 'next to' as the
association between the State button and the option is obvious enough.

-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Peter Whaite wrote:

>Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>  
>
>>Thanks, but are there really state buttons that are not next to options? Is
>>not both yours and mine sentence wrong then? Or can you give an example,
>>please?
>>    
>>
>
>At the top of every customize group page there is a global state button
>that can be used to set or save all the options that have been changed
>in the page, e.g.
>
>/- Emacs group: ---------------------------------------------------------\
>      State: visible group members are all at standard settings.
>   Customization of the One True Editor.
>   See also Manual.
>
>No big deal, though I don't think its necessary to say 'next to' as the
>association between the State button and the option is obvious enough.
>  
>
Based on the feed back I made a new patch. I added the mouse over face 
(requires a small change to wid-edit.el - I think Per A hinted about 
that earlier) and rewrote the header text little. There is now also an 
explanation of what a button is in case there are no 
"custom-raised-buttons".

I kept the 'next to' this time, I am not convinced yet ;-)

[-- Attachment #2: cus-edit-links-2.patch --]
[-- Type: text/plain, Size: 4609 bytes --]

Index: cus-edit.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.243
diff -c -r1.243 cus-edit.el
*** cus-edit.el	4 Dec 2005 02:39:24 -0000	1.243
--- cus-edit.el	8 Dec 2005 00:31:47 -0000
***************
*** 1412,1417 ****
--- 1412,1424 ----
  		   'custom-button-pressed
  		 'custom-button-pressed-unraised))))
  
+ (defface custom-link-face
+   `((((class color) (background light)) (:foreground "blue" :underline t))
+     (((class color) (background dark)) (:foreground "cyan" :underline t)))
+   "Face used to highlight attributes that are links."
+   :group 'custom-faces)
+ 
+ 
  (defun custom-buffer-create-internal (options &optional description)
    (custom-mode)
    (if custom-buffer-verbose-help
***************
*** 1419,1445 ****
  	(widget-insert "This is a customization buffer")
  	(if description
  	    (widget-insert description))
! 	(widget-insert (format ".
! %s show active fields; type RET or click mouse-1
! on an active field to invoke its action.  Editing an option value
! changes only the text in the buffer.  Invoke the State button to set or
! save the option value.  Saving an option normally edits your init file.
! Invoke "
! 			       (if custom-raised-buttons
! 				   "`Raised' buttons"
! 				 "Square brackets")))
  	(widget-create 'info-link
! 		       :tag "Custom file"
  		       "(emacs)Saving Customizations")
  	(widget-insert
! 	 " for information on how to save in a different file.
! Invoke ")
  	(widget-create 'info-link
! 		       :tag "Help"
  		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for general information.\n\n")
! 	(widget-insert "Operate on everything in this buffer:\n "))
      (widget-insert " "))
    (widget-create 'push-button
  		 :tag "Set for Current Session"
--- 1426,1461 ----
  	(widget-insert "This is a customization buffer")
  	(if description
  	    (widget-insert description))
! 	(widget-insert ".
! 
! Editing an option value changes only the text in the buffer.  The
! State button next to the option can be used to set or save the
! value.
! 
! Saving an option normally edits your init file. See ")
  	(widget-create 'info-link
!                        :button-face 'custom-link-face
!                        :button-prefix ""
!                        :button-suffix ""
!                        :mouse-face 'highlight
! 		       :tag "custom file"
  		       "(emacs)Saving Customizations")
  	(widget-insert
! 	 "\nfor information on how to save in a different file.\n\nSee ")
! 
  	(widget-create 'info-link
!                        :button-face 'custom-link-face
!                        :button-prefix ""
!                        :button-suffix ""
!                        :mouse-face 'highlight
! 		       :tag "help"
  		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for more information.\n\n")
!         (unless custom-raised-buttons
!           (widget-insert
!            "Note: On your display type 'buttons' are represented with square\nbrackets.\n\n"))
! 	(widget-insert "Operate on all options in this buffer:\n "))
      (widget-insert " "))
    (widget-create 'push-button
  		 :tag "Set for Current Session"
***************
*** 2149,2154 ****
--- 2165,2174 ----
  		  (insert " ")
  		  (push (widget-create-child-and-convert
  			 widget 'custom-group-link
+                          :button-face 'custom-link-face
+                          :button-prefix ""
+                          :button-suffix ""
+                          :mouse-face 'highlight
  			 :tag (custom-unlispify-tag-name symbol)
  			 symbol)
  			buttons)
***************
*** 2160,2166 ****
             (when links
               (insert "\nParent documentation: ")
               (while links
!                (push (widget-create-child-and-convert widget (car links))
                       buttons)
                 (setq links (cdr links))
                 (cond ((null links)
--- 2180,2192 ----
             (when links
               (insert "\nParent documentation: ")
               (while links
!                (push (widget-create-child-and-convert
!                       widget (car links)
!                       :button-face 'custom-link-face
!                       :button-prefix ""
!                       :button-suffix ""
!                       :mouse-face 'highlight
!                       )
                       buttons)
                 (setq links (cdr links))
                 (cond ((null links)

[-- Attachment #3: wid-edit-mouse-face.patch --]
[-- Type: text/plain, Size: 2012 bytes --]

Index: wid-edit.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/wid-edit.el,v
retrieving revision 1.155
diff -c -r1.155 wid-edit.el
*** wid-edit.el	16 Nov 2005 22:15:59 -0000	1.155
--- wid-edit.el	8 Dec 2005 00:21:50 -0000
***************
*** 403,409 ****
      ;; We want to avoid the face with image buttons.
      (unless (widget-get widget :suppress-face)
        (overlay-put overlay 'face (widget-apply widget :button-face-get))
!       (overlay-put overlay 'mouse-face widget-mouse-face))
      (overlay-put overlay 'pointer 'hand)
      (overlay-put overlay 'follow-link follow-link)
      (overlay-put overlay 'help-echo help-echo)))
--- 403,410 ----
      ;; We want to avoid the face with image buttons.
      (unless (widget-get widget :suppress-face)
        (overlay-put overlay 'face (widget-apply widget :button-face-get))
!       ;;(overlay-put overlay 'mouse-face widget-mouse-face))
!       (overlay-put overlay 'mouse-face (widget-apply widget :mouse-face-get)))
      (overlay-put overlay 'pointer 'hand)
      (overlay-put overlay 'follow-link follow-link)
      (overlay-put overlay 'help-echo help-echo)))
***************
*** 1390,1395 ****
--- 1391,1397 ----
    :offset 0
    :format-handler 'widget-default-format-handler
    :button-face-get 'widget-default-button-face-get
+   :mouse-face-get 'widget-default-mouse-face-get
    :sample-face-get 'widget-default-sample-face-get
    :delete 'widget-default-delete
    :copy 'identity
***************
*** 1533,1538 ****
--- 1535,1548 ----
  	(if parent
  	    (widget-apply parent :button-face-get)
  	  widget-button-face))))
+ 
+ (defun widget-default-mouse-face-get (widget)
+   ;; Use :mouse-face or widget-mouse-face
+   (or (widget-get widget :mouse-face)
+       (let ((parent (widget-get widget :parent)))
+ 	(if parent
+ 	    (widget-apply parent :mouse-face-get)
+ 	  widget-mouse-face))))
  
  (defun widget-default-sample-face-get (widget)
    ;; Use :sample-face.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: fancy-splash-screen customize group...

[Peter Whaite]

Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
> Based on the feed back I made a new patch. I added the mouse over face
> (requires a small change to wid-edit.el - I think Per A hinted about
> that earlier) and rewrote the header text little. There is now also an
> explanation of what a button is in case there are no
> "custom-raised-buttons".

Looks very nice. 

> I kept the 'next to' this time, I am not convinced yet ;-)

Its good the way you have stated it.  I can live with it :-).

-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Juri Linkov]

>> Thanks, but are there really state buttons that are not next to options? Is
>> not both yours and mine sentence wrong then? Or can you give an example,
>> please?
>
> At the top of every customize group page there is a global state button
> that can be used to set or save all the options that have been changed
> in the page, e.g.
>
> /- Emacs group: ---------------------------------------------------------\
>       State: visible group members are all at standard settings.
>    Customization of the One True Editor.
>    See also Manual.
>
> No big deal, though I don't think its necessary to say 'next to' as the
> association between the State button and the option is obvious enough.

I think more obvious buttons for beginners to press are global state
buttons at the top of every customize group page, not the State button
(which is not quite a button, but rather a popup menu).  What I mean
are the following buttons:

Operate on everything in this buffer:
 [Set for Current Session] [Save for Future Sessions]
 [Reset] [Reset to Saved Erase Customization]   [Finish]

A sentence that mentions these global state buttons would be better, IMO.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

   I think more obvious buttons for beginners to press are global state
   buttons

No, I know for an absolute fact that the opposite is true.

Many of these whole buffer buttons did not work for years without
anybody noticing.  The whole buffer "Reset" and "Reset to Saved"
buttons did not work for five and a half years before somebody
noticed.  The whole buffer "Erase Customization" button _never_ worked
in the eight years in between the time that Custom was first included
in Emacs and a few weeks ago when I (very reluctantly, because it is a
dangerous button) made it work.

The way the "Reset" and "Reset to Saved" buttons were fixed two and a
half years ago very likely introduced bugs because, to make the
buttons work, it removed some checks that in all probability were
there for _some_ reason.  (My fix to "Erase Customization" did not
remove those checks.)  Nobody will ever notice these bugs, if they are
present, however, because nobody ever uses these buttons.

One should under no circumstances encourage anybody, certainly not
beginners, to use these buttons.  They are completely untested: nobody
uses them.  Their code is fragile.  Any apparently unrelated change in
Custom can easily badly break them badly without warning (and nobody
will notice, because nobody uses them).  Their effect is so drastic
that bugs in them can have very bad consequences.  Especially those
three "Reset" type buttons are very bad.

If you use any of these whole buffer buttons, then I strongly
recommend that you use numbered backups of your Custom file and never
automatically delete any of them.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Juri Linkov]

> If you use any of these whole buffer buttons, then I strongly
> recommend that you use numbered backups of your Custom file and never
> automatically delete any of them.

I use whole buffer buttons only in single option buffers, i.e. buffers
created by `customize-option' or `customize-face'.  I use them as a fast
way to set an option in .emacs.  I usually do `C-h v some-variable',
read its documentation, type `customize-option', change its default value
and invoke `save' on the customization buffer.  For face customization,
I type `C-u C-x = TAB RET' or `customize-face' on a highlighted character,
and then invoke `save' in the face customization buffer.

Even if this is a typical way for most people to use Customize, of course
this doesn't mean that multi-option group customization buffers should be left
in a non-working state for years.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Juri Linkov wrote:

   I use whole buffer buttons only in single option buffers, i.e. buffers
   created by `customize-option' or `customize-face'.

In those buffers they are OK, as I already pointed out earlier.

   Even if this is a typical way for most people to use Customize,

I would guess that customize-group and customize-browse are used by
many beginning or advanced users.  Several people stated that they
regularly use customize-apropos, which yields a multi-option buffer.
Custom is very useful to browse options, not just to set them.

   of course this doesn't mean that multi-option group customization
   buffers should be left in a non-working state for years.

They were not _deliberately_ left in a non-working state for years.
Nobody knew that they were in a non-working state, because nobody
apparently ever clicked on them for years.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Luc Teirlinck wrote:

>They were not _deliberately_ left in a non-working state for years.
>Nobody knew that they were in a non-working state, because nobody
>apparently ever clicked on them for years.
>  
>
I doubt that nobody clicked on them. Could it not be that our feedback 
mechanisms are a bit too weak to catch things like this? A beginner 
could click those without understanding what was happening and without 
understanding how to ask.

The feedback on a complicated user interface is perhaps problematic?

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

   I doubt that nobody clicked on them. Could it not be that our feedback 
   mechanisms are a bit too weak to catch things like this? A beginner 
   could click those without understanding what was happening and without 
   understanding how to ask.

If anybody sophisticated enough to know how to file a bug report knows
better than to click on these buttons (in multi-option buffers), why
would you want to _encourage_ computer illiterate paople to click on
them (in multi-option buffers)?  They are a lot less likely to be able
to repair any resulting damage than more sophisticated users are.

My point is that people should not be encouraged to use these buttons
(in multi-option buffers) instead of the much safer State buttons.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Peter Whaite]

Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
>
> My point is that people should not be encouraged to use these buttons
> (in multi-option buffers) instead of the much safer State buttons.

If the buttons are as dangerous as you say they shouldn't be in there.

If you haven't already filed a bug report you should, because you have
obviously spent a lot of time analysing this issue.


-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    > My point is that people should not be encouraged to use these buttons
    > (in multi-option buffers) instead of the much safer State buttons.

    If the buttons are as dangerous as you say they shouldn't be in there.

We are not going to change this now.
Please don't ask people to propose that kind of change.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    >They were not _deliberately_ left in a non-working state for years.
    >Nobody knew that they were in a non-working state, because nobody
    >apparently ever clicked on them for years.
    >  
    >
    I doubt that nobody clicked on them. Could it not be that our feedback 
    mechanisms are a bit too weak to catch things like this? A beginner 
    could click those without understanding what was happening and without 
    understanding how to ask.

If you (plural) want to argue about this, would you please
take it off the list, so that it stops being a distraction?
This argument is not going to affect my decisions; I can't
even spare the time to read it all.

unexec and fedora core 4

[Camm Maguire]

Greetings!  I am a developer of GCL, which shares unexec with emacs.
I have noticed on certain recent Fedora Core 4 machines, binaries
produced with unexec cannot mprotect memory (allocated with brk)
PROT_EXEC (returning EACCESS, i.e. permission denied), whereas
binaries output by ld can do so just fine.  This does not vary with
exec-shield or randomize_va_space settings, and appears quite machine
specific.  The same binary which functions perfectly normally on one
fc4 machine shows this failure only on another machine.  I have as yet
been unable to correlate this with dynamic library placement, or other
settings in /proc/sys.

If this rings any bells with anyone, I'd be most appreciative for any
enlightenment. 

Take care,
-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: unexec and fedora core 4

[Richard M. Stallman]

How about asking some Fedora developers to help you?
(I don't know how to reach them.)

Re: Re: unexec and fedora core 4

[Camm Maguire]

Juho Snellman <jsnell@iki.fi> writes:

> <camm@enhanced.com> wrote:
> > Greetings!  I am a developer of GCL, which shares unexec with emacs.
> > I have noticed on certain recent Fedora Core 4 machines, binaries
> > produced with unexec cannot mprotect memory (allocated with brk)
> > PROT_EXEC (returning EACCESS, i.e. permission denied), whereas
> > binaries output by ld can do so just fine.  This does not vary with
> > exec-shield or randomize_va_space settings, and appears quite machine
> > specific.  The same binary which functions perfectly normally on one
> > fc4 machine shows this failure only on another machine.  I have as yet
> > been unable to correlate this with dynamic library placement, or other
> > settings in /proc/sys.
> 
> Just a guess, but this might be related to SELinux. Do the machines
> have differences in /etc/selinux/config?
> 

Bingo! (I think)  The config files are identical, but the problem
machine has a 'strict' subdirectory with a host of files and options.
Any idea of what I should look for herein, and what this could have to
do with unexec vs ld?

Thank you so much!

> -- 
> Juho Snellman
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: Re: unexec and fedora core 4

[Camm Maguire]

Greetings!

OK, here is what I believe now to be the case -- the SELinux option
allow_execmem, which is 'active' on the bad box, is causing the
problem.  All is well if one takes the drastic action of 

sudo /bin/sh -c "/usr/sbin/setenforce 0"

but will probably allso work if one changes

/etc/selinux/strict/src/policy/domains/user.te:bool allow_execmem false;

to

/etc/selinux/strict/src/policy/domains/user.te:bool allow_execmem true;

and 

sudo /bin/sh -c "cd /etc/selinux/strict/src/policy && make load"

though I have not confirmed this not wanting to hose the machine in
question. 

The security people appear to persist in their (IMHO quite erroneous)
assumption that there is no legitimate need for an executable heap.
Tim Daly likely has further thoughts on this, but I saw the comment
again here:

http://copilotconsulting.com/mail-archives/selinux.2005/msg02006.html

Take care,

Camm Maguire <camm@enhanced.com> writes:

> Juho Snellman <jsnell@iki.fi> writes:
> 
> > <camm@enhanced.com> wrote:
> > > Greetings!  I am a developer of GCL, which shares unexec with emacs.
> > > I have noticed on certain recent Fedora Core 4 machines, binaries
> > > produced with unexec cannot mprotect memory (allocated with brk)
> > > PROT_EXEC (returning EACCESS, i.e. permission denied), whereas
> > > binaries output by ld can do so just fine.  This does not vary with
> > > exec-shield or randomize_va_space settings, and appears quite machine
> > > specific.  The same binary which functions perfectly normally on one
> > > fc4 machine shows this failure only on another machine.  I have as yet
> > > been unable to correlate this with dynamic library placement, or other
> > > settings in /proc/sys.
> > 
> > Just a guess, but this might be related to SELinux. Do the machines
> > have differences in /etc/selinux/config?
> > 
> 
> Bingo! (I think)  The config files are identical, but the problem
> machine has a 'strict' subdirectory with a host of files and options.
> Any idea of what I should look for herein, and what this could have to
> do with unexec vs ld?
> 
> Thank you so much!
> 
> > -- 
> > Juho Snellman
> > 
> > 
> > 
> > _______________________________________________
> > Gcl-devel mailing list
> > Gcl-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/gcl-devel
> > 
> > 
> > 
> 
> -- 
> Camm Maguire			     			camm@enhanced.com
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: [Gcl-devel] Re: unexec and fedora core 4

[Eli Zaretskii]

> From: Camm Maguire <camm@enhanced.com>
> Date: 09 Dec 2005 16:43:44 -0500
> Cc: gcl-devel@gnu.org, emacs-devel@gnu.org, root <daly@axiom-developer.org>,
> 	Matt Kaufmann <kaufmann@cs.utexas.edu>,
> 	axiom-developer@nongnu.org, Sandip Ray <sandip@cs.utexas.edu>
> 
> OK, here is what I believe now to be the case -- the SELinux option
> allow_execmem, which is 'active' on the bad box, is causing the
> problem.  All is well if one takes the drastic action of 
> 
> sudo /bin/sh -c "/usr/sbin/setenforce 0"
> 
> but will probably allso work if one changes
> 
> /etc/selinux/strict/src/policy/domains/user.te:bool allow_execmem false;
> 
> to
> 
> /etc/selinux/strict/src/policy/domains/user.te:bool allow_execmem true;
> 
> and 
> 
> sudo /bin/sh -c "cd /etc/selinux/strict/src/policy && make load"
> 
> though I have not confirmed this not wanting to hose the machine in
> question. 

Should we add something along these lines to etc/PROBLEMS?

Re: [Gcl-devel] Re: unexec and fedora core 4

[Camm Maguire]

Greetings!

Eli Zaretskii <eliz@gnu.org> writes:

> > question. 
> 
> Should we add something along these lines to etc/PROBLEMS?
> 

Don't know what this list is, but sounds advisable.  I would also
advise not setting allow_execmem in strict mode by default.

take care,

> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

>From my previous message:

   Many of these whole buffer buttons did not work for years without
   anybody noticing.

To clarify: with "did not work" I meant that they were complete no-ops.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

>From my previous message:
   
   One should under no circumstances encourage anybody, certainly not
   beginners, to use these buttons.  They are completely untested: nobody
   uses them.  Their code is fragile.  Any apparently unrelated change in
   Custom can easily badly break them badly without warning (and nobody
   will notice, because nobody uses them).

Let me give one example of what I mean with:

   Their code is fragile.  Any apparently unrelated change in
   Custom can easily badly break them badly without warning

These whole buffer buttons do not operate on options whose value is
"hidden".  That is, options whose value is hidden will not be saved,
set or reset by these buttons.  A while ago somebody suggested that
this was counterintuitive and that beginners would expect them to
operate on options with hidden values.  It was suggested by some to
make the whole buffer buttons operate on such options.  Fortunately,
that was never implemented.

The correct functioning of the whole buffer buttons relies heavily on
the fact that they do not operate on options whose values is hidden.
This is not at all obvious, unless you study the code carefully:
nobody involved in the discussion about these options apparently
realized it.  (I did not realize it myself at the time.)

If the suggested change would have been implemented, the whole buffer
buttons would have started to operate on child groups and recursively
on their "offspring" groups.  The results would have been disastrous to
users of these buttons.

In general, any change in the way hidden values are implemented or
treated could easily badly mess up these whole buffer buttons in a
very non-obvious way.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Luc Teirlinck wrote:

>>From my previous message:
>   
>   One should under no circumstances encourage anybody, certainly not
>   beginners, to use these buttons.  They are completely untested: nobody
>   uses them.  Their code is fragile.  Any apparently unrelated change in
>   Custom can easily badly break them badly without warning (and nobody
>   will notice, because nobody uses them).
>
>Let me give one example of what I mean with:
>  
>
Thanks for your explanations. May I then suggest that we start using 
these buttons and Custom in general? I have already done so for quite a 
while. Without using Custom I felt it was difficult to have any opinion 
on it. (Of course using it makes it a bit difficult to have opinions on 
the look and feel instead, because you get used to it but that is 
another story.)

I always use the top buttons for changing things. Though I seldom use 
customize-group to change anything. I use it however to get an overview 
over options (though the current layout is not very good for that).

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Lennart Borgman wrote:

   I always use the top buttons for changing things. Though I seldom use 
   customize-group to change anything.

Sorry, I somehow forgot to say that the problems I pointed out apply
to the whole buffer buttons in _group_ buffers (actually, most of them
apply to any Custom buffer with more than one option).  In as far as I
know they are safe to use in buffers with an individual option or face
and I use them myself in such buffers.

The fact that three out of the five buttons were no-ops during most of
their existence and that nobody noticed applies to _group_ buffers.

The fact that I am afraid that the whole buffer buttons could all of a
sudden start recursively descending into subgroups by somebody making
some apparently unrelated change for completely unrelated reasons
applies to all buffers that can contain subgroups, that is, not only
group buffers, but also buffers you get with, for instance,
customize-apropos.

   May I then suggest that we start using these buttons and Custom in
   general? I have already done so for quite a while.

I do use Custom extensively, but I never use the whole buffer buttons,
_except_ in single option buffers.  Since you essentially only use
Custom in such buffers, you are actually in the same situation that I
am, for different reasons.  Though I have actually (carefully, I hope)
fixed a bug in them on one occasion, I do not like to spend a lot of
time studying and debugging these whole buffer buttons in non-single
option buffers, since I believe that they are bad design in non-single
option buffers to begin with.

   Though I seldom use customize-group to change anything. I use it
   however to get an overview over options (though the current layout
   is not very good for that).

Have you ever used the "intended" way to find options, customize-browse
at all?  If you only use customize-{face,variable,group} or
`M-x customize', then _obviously_ things are difficult to find.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

It might be good to point out a possible source of misunderstanding.

You use Custom mainly to customize individual options.  So, if you
talk about Custom buffers without specifying which ones, you are
probably thinking about single option buffers.

I mainly use Custom to see how I can customize one particular part of
Emacs, using customize-group.  (Or to browse through the groups and
options with customize-browse.)  So if I talk about Custom buffers,
without specifying which ones, I am mainly thinking about group buffers.

Obviously, things should work well in _all_ kinds of Custom buffers.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Unless I misunderstand your patch seems to take out the link to
"Custom File".  If so, why?

   There is one thing that I have not found out how to change it: the 
   "mouse over" face. It is gray whatever I do. If someone knows how to 
   make a widget really display the highlight face then please tell me!

I suggest to wait with all your changes until after the release.  The
release will _never_ happen if we continue to be distracted by stuff
like this.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Chong Yidong]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I suggest to wait with all your changes until after the release.  The
> release will _never_ happen if we continue to be distracted by stuff
> like this.

The way the Emacs release criteria is set up, the release process is
stuck until the string_free_list/cons_free_list related crash bug that
happens to some people is resolved.  There's no reason to think that
these changes will affect that.

If no one is able to resolve the crasher bug (and there's no reason to
think that it will happen soon), we will be stuck forever.  So we
shouldn't stop making improvements to Emacs.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Luc Teirlinck wrote:

>Unless I misunderstand your patch seems to take out the link to
>"Custom File".  If so, why?
>  
>
I made that temporary to get some feed back on it. It is perhaps not so 
easy to find in the documentation that the "help" links open, but a 
slight change there would make it easy. I prefer that and Peter also 
suggested removing the "custom file" link.

>I suggest to wait with all your changes until after the release.  The
>release will _never_ happen if we continue to be distracted by stuff
>like this.
>  
>
Do you really think that this will delay the release? Do you think the 
change will break anything? In my opinion it seems unlikely, but not 
impossible. Of course this discussion might delay it a bit. Though I 
have the feeling that this discussion is near the end. Or do you think 
differently?

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

   I made that temporary to get some feed back on it.

The link was put in on explicit request of people who objected against
programs writing in their init files.  It makes little sense to put in
the button each time somebody asks for it and remove it each time
somebody suggests to remove it.

   It is perhaps not so easy to find in the documentation that the
   "help" links open, but a slight change there would make it easy.

Some people want to know straight offhand that they can save in a
different file if they want to.

   Peter also suggested removing the "custom file" link.

On the ground that it was useless for beginners.  But a dislike for
programs writing into your initialization files has nothing to do with
how long you have been using Emacs.  People want to know that
information _before_ they start using Custom.  So we are actually
talking about complete beginners in as far as Custom is concerned.

Sincerely,

Luc.
2

Re: fancy-splash-screen customize group...

[Peter Whaite]

Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> Unless I misunderstand your patch seems to take out the link to
> "Custom File".  If so, why?
>
I suggested that because its something only experts would be interested
in, and they can easily find it by following the help link.


-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Peter Whaite wrote:
   
   I suggested that because its something only experts would be interested
   in, and they can easily find it by following the help link.

As I pointed out in my earlier message, I believe that you
misunderstand the reasons why that link was put in.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Peter Whaite]

Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> Peter Whaite wrote:
>    
>    I suggested that because its something only experts would be interested
>    in, and they can easily find it by following the help link.
> 
> As I pointed out in my earlier message, I believe that you
> misunderstand the reasons why that link was put in.

Just for the record I do understand the reasons and I sympathise with
them.  However I disagree that inserting the link was the correct thing
to do in the first place.

-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    > Unless I misunderstand your patch seems to take out the link to
    > "Custom File".  If so, why?
    >
    I suggested that because its something only experts would be interested
    in, and they can easily find it by following the help link.

Indeed, the Help link takes one to a node whose menu includes Saving
Customizations.  I think we should change that menu item to

* Saving Customizations::    How to save customizations in a different file.

Whether to delete the Custom File button is a different question.
For now, it seems useful to leave it.

Re: fancy-splash-screen customize group...

[Peter Whaite]

Richard M. Stallman <rms@gnu.org> wrote:
> 
> Indeed, the Help link takes one to a node whose menu includes Saving
> Customizations.  I think we should change that menu item to
> 
> * Saving Customizations::    How to save customizations in a different
>   file.

Yes this is much better.

There is still no clear item telling people how to find customizations
though.  I think there should be a new item, 'Finding Customizations'.

> Whether to delete the Custom File button is a different question.
> For now, it seems useful to leave it.

I don't see why.  The latest customization patch from Lennart is a big
improvement, and the preamble now reads:

    Editing an option value changes only the text in the buffer.  The
    State button next to the option can be used to set or save the value.

    Saving an option normally edits your init file. See [custom file]
    for information on how to save in a different file.

    See [help] for more information.

I would still delete the sentence "See [custom file]..." though:

    Saving an option normally edits your init file.  See [help] for more
    information.

The word "normally" will tell anyone who really cares that
customizations dont have to be saved in .emacs, and then they will look
at the help where, with the change above, they will immediately find the
answer.



-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    > Whether to delete the Custom File button is a different question.
    > For now, it seems useful to leave it.

    I don't see why.

1. It is preferable to change less.

2. Someone explained the specific motivation for it.

I have made the decision.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    There is still no clear item telling people how to find customizations
    though.  I think there should be a new item, 'Finding Customizations'.

What would this node contain?

Re: fancy-splash-screen customize group...

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Richard M. Stallman wrote:

>    There is still no clear item telling people how to find customizations
>    though.  I think there should be a new item, 'Finding Customizations'.
>
>What would this node contain?
>  
>
I have attached a suggestion for this (actually in a reply to a previous 
message where you asked for this). It also changes to

! * Saving Customizations::    How to save customizations in a different 
file.
!                                 And why they can not be saved when 
emacs was
!                                 invoked with -Q.


[-- Attachment #2: custom.texi-searching.patch --]
[-- Type: text/plain, Size: 3009 bytes --]

Index: custom.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/man/custom.texi,v
retrieving revision 1.94
diff -c -r1.94 custom.texi
*** custom.texi	9 Dec 2005 00:30:08 -0000	1.94
--- custom.texi	9 Dec 2005 17:38:59 -0000
***************
*** 206,213 ****
  
  @menu
  * Groups: Customization Groups.   How options are classified in a structure.
  * Changing a Variable::      How to edit a value and set an option.
! * Saving Customizations::    Details of saving customizations.
  * Face Customization::       How to edit the attributes of a face.
  * Specific Customization::   Making a customization buffer for specific
                                  variables, faces, or groups.
--- 206,216 ----
  
  @menu
  * Groups: Customization Groups.   How options are classified in a structure.
+ * Searching for Options::    How to search for options using regexps.
  * Changing a Variable::      How to edit a value and set an option.
! * Saving Customizations::    How to save customizations in a different file.
!                                 And why they can not be saved when emacs was
!                                 invoked with -Q.
  * Face Customization::       How to edit the attributes of a face.
  * Specific Customization::   Making a customization buffer for specific
                                  variables, faces, or groups.
***************
*** 291,296 ****
--- 294,307 ----
  that group and its contents, just that variable, or just that face.
  This is the way to set values in it.
  
+ @node Searching for Options
+ @subsection Searching for Options
+ 
+   You can search for customization options and groups by name using
+ regular expressions. The search functions are available in the menus
+ under Options - Customize Emacs.  See also the function
+ customize-apropos in (@pxref{Specific Customization}).
+ 
  @node Changing a Variable
  @subsection Changing a Variable
  
***************
*** 609,615 ****
  Set up a customization buffer with just one group, @var{group}.
  @item M-x customize-apropos @key{RET} @var{regexp} @key{RET}
  Set up a customization buffer with all the variables, faces and groups
! that match @var{regexp}.
  @item M-x customize-changed-options @key{RET} @var{version} @key{RET}
  Set up a customization buffer with all the variables, faces and groups
  whose meaning has changed since Emacs version @var{version}.
--- 620,628 ----
  Set up a customization buffer with just one group, @var{group}.
  @item M-x customize-apropos @key{RET} @var{regexp} @key{RET}
  Set up a customization buffer with all the variables, faces and groups
! that match @var{regexp}. There are also more specific functions:
! customize-apropos-options, customize-apropos-faces and
! customize-apropos-groups.
  @item M-x customize-changed-options @key{RET} @var{version} @key{RET}
  Set up a customization buffer with all the variables, faces and groups
  whose meaning has changed since Emacs version @var{version}.

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: fancy-splash-screen customize group...

[Peter Whaite]

Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> Richard M. Stallman wrote:
> 
> >    There is still no clear item telling people how to find customizations
> >    though.  I think there should be a new item, 'Finding Customizations'.
> >
> >What would this node contain?
> >
> I have attached a suggestion for this (actually in a reply to a previous
> message where you asked for this).

Yes, thats what I was thinking.  Thanks Lennart.

As I said earlier, it is unnecessary to mention not being able to save
when -Q etc are in effect.  It only clutters up the node.


-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

I don't want to make these changes, for the following reasons:

    ! * Saving Customizations::    How to save customizations in a different file.
    !                                 And why they can not be saved when emacs was
    !                                 invoked with -Q.

Menu items should not be that detailed--it is clumsy.

    + @node Searching for Options
    + @subsection Searching for Options
    + 
    +   You can search for customization options and groups by name using
    + regular expressions. The search functions are available in the menus
    + under Options - Customize Emacs.  See also the function
    + customize-apropos in (@pxref{Specific Customization}).

Such small nodes are wasteful and undesirable.

      @item M-x customize-apropos @key{RET} @var{regexp} @key{RET}
      Set up a customization buffer with all the variables, faces and groups
    ! that match @var{regexp}. There are also more specific functions:
    ! customize-apropos-options, customize-apropos-faces and
    ! customize-apropos-groups.

In a table which is structured as one command per item,
it is inconsistent to mention other commands in the same item.

I do not see why it is worth documenting customize-apropos-options,
etc.  customize-apropos seems to be good enough.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

Richard M. Stallman wrote:

>I don't want to make these changes, for the following reasons:
>
>    ! * Saving Customizations::    How to save customizations in a different file.
>    !                                 And why they can not be saved when emacs was
>    !                                 invoked with -Q.
>
>Menu items should not be that detailed--it is clumsy.
>  
>
Ok, I have removed removed "And why ..."

>    + @node Searching for Options
>    + @subsection Searching for Options
>    + 
>    +   You can search for customization options and groups by name using
>    + regular expressions. The search functions are available in the menus
>    + under Options - Customize Emacs.  See also the function
>    + customize-apropos in (@pxref{Specific Customization}).
>
>Such small nodes are wasteful and undesirable.
>  
>
I do not understand why they are wasteful, but I have added some more 
information which I believe is useful.

>      @item M-x customize-apropos @key{RET} @var{regexp} @key{RET}
>      Set up a customization buffer with all the variables, faces and groups
>    ! that match @var{regexp}. There are also more specific functions:
>    ! customize-apropos-options, customize-apropos-faces and
>    ! customize-apropos-groups.
>
>In a table which is structured as one command per item,
>it is inconsistent to mention other commands in the same item.
>  
>
I removed customize-apropos-* here.

I have attached a new patch.

>I do not see why it is worth documenting customize-apropos-options,
>etc.  customize-apropos seems to be good enough.
>  
>
Maybe customize-apropos should prompt for searching just options, faces 
or groups?

[-- Attachment #2: custom.texi-searching2.patch --]
[-- Type: text/plain, Size: 2372 bytes --]

Index: custom.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/man/custom.texi,v
retrieving revision 1.95
diff -c -r1.95 custom.texi
*** custom.texi	10 Dec 2005 00:46:09 -0000	1.95
--- custom.texi	10 Dec 2005 14:29:08 -0000
***************
*** 206,213 ****
  
  @menu
  * Groups: Customization Groups.   How options are classified in a structure.
  * Changing a Variable::      How to edit a value and set an option.
! * Saving Customizations::    Details of saving customizations.
  * Face Customization::       How to edit the attributes of a face.
  * Specific Customization::   Making a customization buffer for specific
                                  variables, faces, or groups.
--- 206,214 ----
  
  @menu
  * Groups: Customization Groups.   How options are classified in a structure.
+ * Searching: Searching for Options.    How to search for options using regexps.
  * Changing a Variable::      How to edit a value and set an option.
! * Saving Customizations::    How to save customizations in a different file.
  * Face Customization::       How to edit the attributes of a face.
  * Specific Customization::   Making a customization buffer for specific
                                  variables, faces, or groups.
***************
*** 290,295 ****
--- 291,314 ----
  that active field creates an ordinary customization buffer showing just
  that group and its contents, just that variable, or just that face.
  This is the way to set values in it.
+ 
+ @node Searching for Options
+ @subsection Searching for Options
+ 
+   You can search for customization options and groups by name using
+ regular expressions.  The search result is shown in the customization
+ buffer which is setup with all matching options of the choosen kind.
+ 
+   To start a search you can use @kbd{M-x customize-apropos} (see
+ @pxref{Specific Customization}).  The search functions are also
+ available in the menus under Options - Customize Emacs.
+ 
+   Tip 1: In the customization buffer you can use @pxref{Incremental
+ Search} like in any other buffer.
+ 
+   Tip 2: If you did not find exactly what you searched for you may find
+ the links to `Parent groups' (if there are any parent groups) beneath
+ the options in the customization buffer useful.
  
  @node Changing a Variable
  @subsection Changing a Variable

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Lennart Borgman wrote:

   I do not understand why they are wasteful, but I have added some more 
   information which I believe is useful.

Useful to make the node longer and hence get around Richard's
objection?  `customize-apropos' is _already_ described under
`(emacs)Specific Customization', where it belongs.  Your node just
duplicates stuff.

Space in the Emacs manual is at a premium.  With the same amount of
space you want to add one could document useful additional features.

   Maybe customize-apropos should prompt for searching just options, faces 
   or groups?

No, one should avoid unnecessary prompts.  One could list the
customize-apropos-* commands in a short sentence in the detailed
description of customize-apropos (rather than in the @item as you
proposed), but I believe that Richard objects against any amount of
space for them.  (But I may be misunderstanding this.)

In as far as finding options is concerned, the best way to find
options is customize-browse.  _That_ is the one we should emphasize.
I have used it since Custom was first included with Emacs and have
never had trouble finding options _except_ when there was trouble with
the individual option: bad group, unclear name, unclear documentation.
(As in the case which started this thread before it went off on a
completely unrelated tangent.)

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Luc Teirlinck wrote:

>Lennart Borgman wrote:
>
>   I do not understand why they are wasteful, but I have added some more 
>   information which I believe is useful.
>
>Useful to make the node longer and hence get around Richard's
>objection?
>
Maybe not only that ;-)

>  `customize-apropos' is _already_ described under
>`(emacs)Specific Customization', where it belongs.  Your node just
>duplicates stuff.
>  
>
You are perhaps right, but I wonder if that is enough. With my first 
proposal I tried to just point to that documentation. The advantage of 
doing so is that it requires very little new text while it as the same 
time makes it more obvious that you can search for options. _Emphasis 
that you can search for options_ is the main purpose of my proposals. 
This was what was asked for I believe.

In my current proposal I am trying to understand what Richard meant. 
What resource is wasted? I focus on the human here. (Some may call this 
a "how to" perspective.) Is there anything the reader of this node would 
want to know more that would be good to tell here?

Maybe you would want to comment from this perspective? What would you 
want to remove? Is there anything else you would like to include?

>In as far as finding options is concerned, the best way to find
>options is customize-browse.  _That_ is the one we should emphasize.
>  
>
I do agree that customize-browse is good, but it is still not my first 
tool for finding an option. In fact I seldom use it, but at times I use 
it to get an overview.

In the first tip I tell about using "Parent groups" in the search 
results. This tells rather much about how I use to work (not only with 
custom): First I do a broad search, then I look more in detail around 
the most interesting search hits. I use this process on the Internet, in 
manuals etc. (And in fact it is the way you have to look for max-min 
values in a multidimensional function.)

>I have used it since Custom was first included with Emacs and have
>never had trouble finding options _except_ when there was trouble with
>the individual option: bad group, unclear name, unclear documentation.
>  
>
Those are very important issues here of course.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Lennart Borgman wrote:

   I do agree that customize-browse is good, but it is still not my first 
   tool for finding an option. In fact I seldom use it, but at times I use 
   it to get an overview.

One important thing to realize if you rely too exclusively on
customize-apropos (or on other apropos commands for that matter) is
that the buffer produced by customize-apropos does _not_ contain all
customizable options, faces and groups matching your regexp, but
_only_ those that are loaded.  This is a weakness of all the apropos
functions.  On the other hand, customize-browse will load everything
as needed.

Sincerely,

Luc.

RE: fancy-splash-screen customize group...

[Drew Adams]

       I do agree that customize-browse is good, but it is still
       not my first tool for finding an option. In fact I seldom
       use it, but at times I use it to get an overview.

    One important thing to realize if you rely too exclusively on
    customize-apropos (or on other apropos commands for that matter) is
    that the buffer produced by customize-apropos does _not_ contain all
    customizable options, faces and groups matching your regexp, but
    _only_ those that are loaded.  This is a weakness of all the apropos
    functions.  On the other hand, customize-browse will load everything
    as needed.

Yes, this is important. Why not add this information to the doc strings of
the customize-apropos* commands? It would be sufficient to add the qualifier
"loaded":

 - customize-apropos: "Customize all loaded user options matching REGEXP"

 - customize-apropos-faces: "Customize all loaded user faces matching
REGEXP"

 - customize-apropos-groups: "Customize all loaded user groups matching
REGEXP"

 - customize-apropos-options: "Customize all loaded user options matching
REGEXP"

Likewise, for the regular apropos commands, if they have similar behavior.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Drew Adams wrote:

   Yes, this is important. Why not add this information to the doc strings of
   the customize-apropos* commands?

and:

   Likewise, for the regular apropos commands, if they have similar behavior.

I _will_ say something about it in man/custom.texi, when I send my patch.

In as far as the docstrings go, my remark that only loaded stuff is
found applies to most of Emacs: all apropos functions, C-h v, C-h f
and friends, and so on.  So _many_ docstrings would have to be changed
if we wanted to be consistent.  `customize' and `customize-browse' are
isolated exceptions to the general rule, because Custom stores extra
info in its groups.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    Yes, this is important. Why not add this information to the doc strings of
    the customize-apropos* commands? It would be sufficient to add the qualifier
    "loaded":

     - customize-apropos: "Customize all loaded user options matching REGEXP"

     - customize-apropos-faces: "Customize all loaded user faces matching
    REGEXP"

     - customize-apropos-groups: "Customize all loaded user groups matching
    REGEXP"

     - customize-apropos-options: "Customize all loaded user options matching
    REGEXP"

I agree--could someone please add "loaded"?
(However, we don't talk about "user faces",
and a "user group" is a group of people such as a GLUG,
not a part of Emacs.)

RE: fancy-splash-screen customize group...

[Drew Adams]

        Yes, this is important. Why not add this information to the 
        doc strings of
        the customize-apropos* commands? It would be sufficient to 
        add the qualifier "loaded":
    
         - customize-apropos: "Customize all loaded user options 
           matching REGEXP"
    
         - customize-apropos-faces: "Customize all loaded user 
           faces matching REGEXP"
    
         - customize-apropos-groups: "Customize all loaded user 
           groups matching REGEXP"
    
         - customize-apropos-options: "Customize all loaded user 
           options matching REGEXP"
    
    I agree--could someone please add "loaded"?

    (However, we don't talk about "user faces",
    and a "user group" is a group of people such as a GLUG,
    not a part of Emacs.)

Sorry - the extra "user"s were artifacts of careless copy&paste.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Richard Stallman wrote:

   I agree--could someone please add "loaded"?

Done.  However, the question remains whether we want to add "loaded"
at all places were it applies: other apropos commands, `C-h v' and
friends, minibuffer completion and countless others (we will never
be able to think of all of them).

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    Done.  However, the question remains whether we want to add "loaded"
    at all places were it applies: other apropos commands, `C-h v' and
    friends, minibuffer completion and countless others (we will never
    be able to think of all of them).

Probably we should not.  This is not a matter where consistency
is important, because there is no contradiction when one place
says "loaded" and another does not.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    In my current proposal I am trying to understand what Richard meant. 
    What resource is wasted? I focus on the human here.

Each detail that we put in the manual makes it a greater
complexity burden for the reader.  It is also more paper
when we print it, and thus more expensive.

It is also more work for us, but that is not a big issue
for a small change.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    In as far as finding options is concerned, the best way to find
    options is customize-browse.  _That_ is the one we should emphasize.

Can you propose a patch to the manual to make this more prominent?

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Richard Stallman wrote:

       In as far as finding options is concerned, the best way to find
       options is customize-browse.  _That_ is the one we should emphasize.

   Can you propose a patch to the manual to make this more prominent?

and (in response to Lennart Borgman):

   Your latest patch is ok, but it has problems of Texinfo usage.
   Would someone like to correct the style?

These two do not seem to go very well together.  It would be easier
for me to propose a patch making `customize-browse' more prominent and
maybe better explaining its relation with `customize' and
`customize-apropos' without Lennart's node added.

If you would read through the entire "Easy Customization" section, you
would see that Lennart's node just repeats in other words what is
already described in other nodes in that section.  Redundancy not only
wastes space, but can also be confusing and annoying to the reader.

Essentially, I believe that one needs a new node with nearly the same
title as Lennart's node but mainly describing customize-browse.  I
would move the current description of customize-browse into that node
rather than repeating it.  The node could briefly mention
customize-apropos, with an @anchor to its detailed description.  That
would achieve the same purpose as Lennart's patch (pointing out that
customize-apropos is an alternate way to find options) with a short
sentence, rather than with a node.

I do not have the time to send a patch this evening, but I could do so
relatively soon.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Luc Teirlinck wrote:

>Essentially, I believe that one needs a new node with nearly the same
>title as Lennart's node but mainly describing customize-browse.  I
>would move the current description of customize-browse into that node
>rather than repeating it.  The node could briefly mention
>customize-apropos, with an @anchor to its detailed description.  That
>would achieve the same purpose as Lennart's patch (pointing out that
>customize-apropos is an alternate way to find options) with a short
>sentence, rather than with a node.
>  
>
I must admit I have made a mistake by not mentioning customize-browse. I 
thought it was covered under Groups for some reason, but apperently it 
is not covered there as I believe.

And the point you made in another letter that the apropos commands only 
finds loaded options is very essential. This makes my approach much less 
useful and it should be pointed out clearly.

So I have no real objections. But I still think that the apropos 
functions should have a prominent place in the node. And to me it was 
not really obvious from the beginning that you could use the usual 
search functions the customize buffer.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Lennart Borgman wrote:

   And to me it was not really obvious from the beginning that you
   could use the usual search functions the customize buffer.

You mean C-s and C-r?  You can use that in _any_ buffer.  (Although a
very few may unfortunately occasionally play tricks on you with the
display property.)

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

	   In as far as finding options is concerned, the best way to find
	   options is customize-browse.  _That_ is the one we should emphasize.

       Can you propose a patch to the manual to make this more prominent?

    and (in response to Lennart Borgman):

       Your latest patch is ok, but it has problems of Texinfo usage.
       Would someone like to correct the style?

    These two do not seem to go very well together.  It would be easier
    for me to propose a patch making `customize-browse' more prominent and
    maybe better explaining its relation with `customize' and
    `customize-apropos' without Lennart's node added.

Ok, please do.

    I do not have the time to send a patch this evening, but I could do so
    relatively soon.

It would be no problem to wait a few days.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

Your latest patch is ok, but it has problems of Texinfo usage.
Would someone like to correct the style?

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Richard Stallman wrote:

   Indeed, the Help link takes one to a node whose menu includes Saving
   Customizations.  I think we should change that menu item to

   * Saving Customizations::    How to save customizations in a different file.

As it stands, there is a problem with this text.  It suggests that if
you are happy with Custom saving into .emacs, you can safely skip this
node.  But it contains the following paragraph, which is useful for
everybody:

   If Emacs was invoked with the `-q' or `--no-init-file' options
(*note Initial Options::), it will not let you save your customizations
in your `~/.emacs' init file.  This is because saving customizations
from such a session would wipe out all the other customizations you
might have on your init file.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Luc Teirlinck wrote:

>Richard Stallman wrote:
>
>   Indeed, the Help link takes one to a node whose menu includes Saving
>   Customizations.  I think we should change that menu item to
>
>   * Saving Customizations::    How to save customizations in a different file.
>
>As it stands, there is a problem with this text.  It suggests that if
>you are happy with Custom saving into .emacs, you can safely skip this
>node.  But it contains the following paragraph, which is useful for
>everybody:
>
>   If Emacs was invoked with the `-q' or `--no-init-file' options
>(*note Initial Options::), it will not let you save your customizations
>in your `~/.emacs' init file.  This is because saving customizations
>from such a session would wipe out all the other customizations you
>might have on your init file.
>  
>
But if you try to save options when using -Q (or -q I guess) then you 
get an error message saying

    "Saving settings from "emacs -q" would overwrite existing 
customizations"

Maybe the text above is not that very important then? However maybe it 
should be changed to something like

    * Saving Customizations:: How to save customizations in a different 
file.
                                                 And why customizations 
are not saved when
                                                 invoking emacs with -Q.

Re: fancy-splash-screen customize group...

[Peter Whaite]

Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> 
>    If Emacs was invoked with the `-q' or `--no-init-file' options
> (*note Initial Options::), it will not let you save your customizations
> in your `~/.emacs' init file.  This is because saving customizations
> from such a session would wipe out all the other customizations you
> might have on your init file.

I must be really dense this morning because I cannot see why its
important to know this.  If you try it you get a message telling you it
can't be done.

What should happen is that the "Save for future sessions" item in
the State pop up menu should be disabled when the --no-init-file option
is in effect.

-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    What should happen is that the "Save for future sessions" item in
    the State pop up menu should be disabled when the --no-init-file option
    is in effect.

I think you have identified a bug.  Does this fix give good results?

*** cus-edit.el	08 Dec 2005 10:48:32 -0500	1.244
--- cus-edit.el	09 Dec 2005 18:35:50 -0500	
***************
*** 1447,1460 ****
  Make your editing in this buffer take effect for this session."
  		 :action (lambda (widget &optional event)
  			   (Custom-set)))
!   (widget-insert " ")
!   (widget-create 'push-button
! 		 :tag "Save for Future Sessions"
! 		 :help-echo "\
  Make your editing in this buffer take effect for future Emacs sessions.
  This updates your Emacs initialization file or creates a new one."
! 		 :action (lambda (widget &optional event)
! 			   (Custom-save)))
    (if custom-reset-button-menu
        (progn
  	(widget-insert " ")
--- 1447,1461 ----
  Make your editing in this buffer take effect for this session."
  		 :action (lambda (widget &optional event)
  			   (Custom-set)))
!   (when user-init-file
!     (widget-insert " ")
!     (widget-create 'push-button
! 		   :tag "Save for Future Sessions"
! 		   :help-echo "\
  Make your editing in this buffer take effect for future Emacs sessions.
  This updates your Emacs initialization file or creates a new one."
! 		   :action (lambda (widget &optional event)
! 			     (Custom-save))))
    (if custom-reset-button-menu
        (progn
  	(widget-insert " ")
***************
*** 2537,2548 ****
    (get (widget-value widget) 'standard-value))
  
  (defvar custom-variable-menu
!   '(("Set for Current Session" custom-variable-set
       (lambda (widget)
         (eq (widget-get widget :custom-state) 'modified)))
!     ("Save for Future Sessions" custom-variable-save
!      (lambda (widget)
!        (memq (widget-get widget :custom-state) '(modified set changed rogue))))
      ("Reset to Current" custom-redraw
       (lambda (widget)
         (and (default-boundp (widget-value widget))
--- 2538,2550 ----
    (get (widget-value widget) 'standard-value))
  
  (defvar custom-variable-menu
!   `(("Set for Current Session" custom-variable-set
       (lambda (widget)
         (eq (widget-get widget :custom-state) 'modified)))
!     ,@(when user-init-file
! 	'(("Save for Future Sessions" custom-variable-save
! 	   (lambda (widget)
! 	     (memq (widget-get widget :custom-state) '(modified set changed rogue))))))
      ("Reset to Current" custom-redraw
       (lambda (widget)
         (and (default-boundp (widget-value widget))
***************
*** 3208,3215 ****
  	     (message "Creating face editor...done"))))))
  
  (defvar custom-face-menu
!   '(("Set for Current Session" custom-face-set)
!     ("Save for Future Sessions" custom-face-save-command)
      ("Reset to Saved" custom-face-reset-saved
       (lambda (widget)
         (or (get (widget-value widget) 'saved-face)
--- 3210,3218 ----
  	     (message "Creating face editor...done"))))))
  
  (defvar custom-face-menu
!   `(("Set for Current Session" custom-face-set)
!     ,@(when user-init-file
! 	'(("Save for Future Sessions" custom-face-save-command)))
      ("Reset to Saved" custom-face-reset-saved
       (lambda (widget)
         (or (get (widget-value widget) 'saved-face)
***************
*** 3798,3809 ****
  	   (insert "/\n")))))
  
  (defvar custom-group-menu
!   '(("Set for Current Session" custom-group-set
       (lambda (widget)
         (eq (widget-get widget :custom-state) 'modified)))
!     ("Save for Future Sessions" custom-group-save
!      (lambda (widget)
!        (memq (widget-get widget :custom-state) '(modified set))))
      ("Reset to Current" custom-group-reset-current
       (lambda (widget)
         (memq (widget-get widget :custom-state) '(modified))))
--- 3801,3813 ----
  	   (insert "/\n")))))
  
  (defvar custom-group-menu
!   `(("Set for Current Session" custom-group-set
       (lambda (widget)
         (eq (widget-get widget :custom-state) 'modified)))
!     ,@(when user-init-file
! 	'(("Save for Future Sessions" custom-group-save
! 	   (lambda (widget)
! 	     (memq (widget-get widget :custom-state) '(modified set))))))
      ("Reset to Current" custom-group-reset-current
       (lambda (widget)
         (memq (widget-get widget :custom-state) '(modified))))

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

       * Saving Customizations::    How to save customizations in a different file.

    As it stands, there is a problem with this text.  It suggests that if
    you are happy with Custom saving into .emacs, you can safely skip this
    node.  But it contains the following paragraph, which is useful for
    everybody:

One cannot expect a single line always to completely describe a topic.
The aim of the manual (and each part of it) is to be helpful--not
particularly to be complete.

We could change it to

* Saving Customizations::    Specifying the file to save customizations in.

but even though strictly speaking it includes the paragraph you
mentioned, I am not sure it is better overall than the other text.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Richard Stallman wrote:

   One cannot expect a single line always to completely describe a topic.
   The aim of the manual (and each part of it) is to be helpful--not
   particularly to be complete.

My objection against the text:

      How to save customizations in a different file.

is not that it is incomplete, but that it is misleading.  It suggests
that anybody who is happy with Custom writing into .emacs should just
skip that node.  If the paragraph I quoted is unnecessary for people
using .emacs, then it would also be unnecessary for people using
another Custom file.

Also, suggesting that the entire node is about saving in a file other
than .emacs makes a possible source of confusion even worse:

       If Emacs was invoked with the `-q' or `--no-init-file' options
    (*note Initial Options::), it will not let you save your customizations
    in your `~/.emacs' init file.  This is because saving customizations
    from such a session would wipe out all the other customizations you
    might have on your init file.

In a section about saving in a file _other_ than `~/.emacs', the above
paragraph seems to imply that customizing in a different file is a
good way to save customizations, even if you used `emacs -q', because,
if you use `~/.emacs', you can not do it (but if you use another file,
you presumably can).

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    My objection against the text:

	  How to save customizations in a different file.

    is not that it is incomplete, but that it is misleading.

Your point is valid as far as it goes, but its magnitude is too small
to matter.  Such minor discrepancies in a table of contents are simply
not worth the amount of concern that you give to them.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    The way the Emacs release criteria is set up, the release process is
    stuck until the string_free_list/cons_free_list related crash bug that
    happens to some people is resolved.  There's no reason to think that
    these changes will affect that.

We have made some progress recently on these two bugs, thanks to your
help.  In fact, didn't we come to suspect that the problem only
happens with hyperthreading?  I think this will be dealt with
fairly soon.

Meanwhile, plenty of other bugs have been reported in the past two
weeks.  They too need to be fixed.  Could people please debug some of
them rather than arguing about the Customize buffer?

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

Your patch that adds custom-link-face seems good to me,
but I think 

    %s indicate buttons; type RET or click mouse-1 to actuate one.
    Editing a field's value changes only the text in the buffer.
    Use the State button of an option or face to set or save changes in it.
    Saving a change normally works by editing your Emacs init file.
    See "

is a better text to use for the initial explanation.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Richard M. Stallman wrote:

>Your patch that adds custom-link-face seems good to me,
>but I think 
>
>    %s indicate buttons; type RET or click mouse-1 to actuate one.
>    Editing a field's value changes only the text in the buffer.
>    Use the State button of an option or face to set or save changes in it.
>    Saving a change normally works by editing your Emacs init file.
>    See "
>
>is a better text to use for the initial explanation.
>  
>
I would prefer something like this:

    This is a customization buffer.

    Editing a field's value changes only the text in the buffer.  The
    State button of an option can be used to set or save the value.
    Options are normally saved in your Emacs init file.  See custom file
    for how to save in a different file and help for more information.

   Note: On your display [Example Button] indicates buttons; type RET or
   click mouse-1 to actuate one.


The "State button can be used" since there are global buttons too. 
"Options are normally saved ..." sounds easier to understand, at least 
to me.

Maybe the only important change is the last paragraph. I believe it 
should come last and that it should only be used in "non-GUI" 
environments. In GUI environments I believe the user recognices the 
buttons and knows what to do with them. If others to not agree with me 
however, I have made [Example Button] a real button (that just says "You 
clicked the Example Button").

A patch is coming later. I believe there are some small errors in 
fill-region that I want to correct.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

	This is a customization buffer.

	Editing a field's value changes only the text in the buffer.  The
	State button of an option can be used to set or save the value.
	Options are normally saved in your Emacs init file.  See custom file
	for how to save in a different file and help for more information.

       Note: On your display [Example Button] indicates buttons; type RET or
       click mouse-1 to actuate one.

Some of your changes are ok with me, but some are not.  You introduced
a passive sentence; please avoid the passive voice whenever that is
reasonably feasible.  Here's what I think is best:

	This is a customization buffer.

	%s shows what a button looks like on your display;
        type RET or click mouse-1 to actuate a button.

	Editing a field's value changes only the text in the buffer.
	To set or save an option, use its State button.
	Options are normally saved in your Emacs init file.
        See custom file for how to save in a
	different file and help for more information.

Regarding

    The "State button can be used" since there are global buttons too. 

They exist, but we are not obliged to mention them here.
This text is simpler if it does not mention them.
Remember, in writing documentation, completeness is NOT the goal!

    If others to not agree with me 
    however, I have made [Example Button] a real button (that just says "You 
    clicked the Example Button").

That is clever.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

Richard M. Stallman wrote:

>Some of your changes are ok with me, but some are not.  You introduced
>a passive sentence; please avoid the passive voice whenever that is
>reasonably feasible.  Here's what I think is best:
>  
>
I have tried to follow this. I have attached a new patch. From my side I 
believe this is ready. Could someone please help me install the patch if 
it is ok? (I am to new to CVS to try to install it myself now.)

I have tried to write a changelog entry also. Eli was kind enough to 
give me some instructions before on how to do this.

** Please notice ***: Looking at the patch for cus-edit.el there is one 
thing I do not understand. There are some lines that adds (defgroup mac 
...). I believe I already have them in my cus-edit.el. Using 
ediff-revision there is no difference for this part, but there is using 
"cvs diff -c cus-edit.el". Weird. Any suggestions? (It is for the same 
file in the same location ...)

[-- Attachment #2: cus-edit-links-5b.patch --]
[-- Type: text/plain, Size: 6769 bytes --]

Index: cus-edit.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.248
diff -c -b -r1.248 cus-edit.el
*** cus-edit.el	16 Dec 2005 03:43:51 -0000	1.248
--- cus-edit.el	19 Dec 2005 15:21:28 -0000
***************
*** 459,464 ****
--- 459,471 ----
    :link '(custom-manual "(emacs)Windows")
    :group 'environment)
  
+ (defgroup mac nil
+   "Mac specific features."
+   :link '(custom-manual "(emacs)Mac OS")
+   :group 'environment
+   :version "22.1"
+   :prefix "mac-")
+ 
  ;;; Utilities.
  
  (defun custom-quote (sexp)
***************
*** 1415,1446 ****
  
  (defun custom-buffer-create-internal (options &optional description)
    (custom-mode)
    (if custom-buffer-verbose-help
!       (progn
  	(widget-insert "This is a customization buffer")
  	(if description
  	    (widget-insert description))
! 	(widget-insert (format ".
! %s show active fields; type RET or click mouse-1
! on an active field to invoke its action.  Editing an option value
! changes only the text in the buffer.  Invoke the State button to set or
! save the option value.  Saving an option normally edits your init file.
! Invoke "
! 			       (if custom-raised-buttons
! 				   "`Raised' buttons"
! 				 "Square brackets")))
  	(widget-create 'info-link
! 		       :tag "Custom file"
  		       "(emacs)Saving Customizations")
  	(widget-insert
! 	 " for information on how to save in a different file.
! Invoke ")
  	(widget-create 'info-link
! 		       :tag "Help"
! 		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for general information.\n\n")
! 	(widget-insert "Operate on everything in this buffer:\n "))
      (widget-insert " "))
    (widget-create 'push-button
  		 :tag "Set for Current Session"
--- 1422,1472 ----
  
  (defun custom-buffer-create-internal (options &optional description)
    (custom-mode)
+   (let ((inhibit-read-only t))
      (if custom-buffer-verbose-help
!         (let ((start (point)))
            (widget-insert "This is a customization buffer")
            (if description
                (widget-insert description))
!           (widget-insert ".")
!           (unless custom-raised-buttons
!             (widget-insert "\n\nThis ")
!             (widget-create 'push-button
!                            :tag "Example Button"
!                            :help-echo "This is just an example button"
!                            :action (lambda (widget &optional event)
!                                      (message
!                                       "\nYou clicked the Example Button!\n")))
!             (widget-insert " shows what a button looks like on your display; " 
!                            "type RET or click mouse-1 to actuate one.")
!             )
!           (widget-insert "
! 
! Editing a field's value changes only the text in the buffer.  To
! save or set an option, use its State button.  Options are
! normally saved in your Emacs init file.  See ")
            (widget-create 'info-link
!                          :button-face 'widget-link-face
!                          :button-prefix ""
!                          :button-suffix ""
!                          :mouse-face 'highlight
!                          :tag "custom file"
!                          :help-echo "Read the online help for Saving Customizations."
                           "(emacs)Saving Customizations")
            (widget-insert
!            " for how to save in a different file and ")
!         
            (widget-create 'info-link
!                          :button-face 'widget-link-face
!                          :button-prefix ""
!                          :button-suffix ""
!                          :mouse-face 'highlight
!                          :tag "help"
!                          :help-echo "Read the online help for Easy Customization Interface."
                           "(emacs)Easy Customization")
!           (widget-insert " for more information.\n\n")
!           (fill-region start (point))
!           (widget-insert "Operate on all options in this buffer:\n "))
        (widget-insert " "))
      (widget-create 'push-button
                     :tag "Set for Current Session"
***************
*** 1452,1459 ****
    (widget-create 'push-button
  		 :tag "Save for Future Sessions"
  		 :help-echo "\
! Make your editing in this buffer take effect for future Emacs sessions.
! This updates your Emacs initialization file or creates a new one."
  		 :action (lambda (widget &optional event)
  			   (Custom-save)))
    (if custom-reset-button-menu
--- 1478,1485 ----
      (widget-create 'push-button
                     :tag "Save for Future Sessions"
                     :help-echo "\
! Make your editing in this buffer take effect for future Emacs sessions."
!                    ;;This updates your Emacs initialization file or creates a new one."
                     :action (lambda (widget &optional event)
                               (Custom-save)))
      (if custom-reset-button-menu
***************
*** 1538,1544 ****
    (widget-setup)
    (buffer-enable-undo)
    (goto-char (point-min))
!   (message "Creating customization setup...done"))
  
  ;;; The Tree Browser.
  
--- 1564,1570 ----
      (widget-setup)
      (buffer-enable-undo)
      (goto-char (point-min))
!     (message "Creating customization setup...done")))
  
  ;;; The Tree Browser.
  
***************
*** 2150,2155 ****
--- 2176,2185 ----
  		  (insert " ")
  		  (push (widget-create-child-and-convert
  			 widget 'custom-group-link
+                          :button-face 'widget-link-face
+                          :button-prefix ""
+                          :button-suffix ""
+                          :mouse-face 'highlight
  			 :tag (custom-unlispify-tag-name symbol)
  			 symbol)
  			buttons)
***************
*** 2165,2171 ****
             (when links
               (insert "\nParent documentation: ")
               (while links
!                (push (widget-create-child-and-convert widget (car links))
                       buttons)
                 (setq links (cdr links))
                 (cond ((null links)
--- 2195,2207 ----
             (when links
               (insert "\nParent documentation: ")
               (while links
!                (push (widget-create-child-and-convert
!                       widget (car links)
!                       :button-face 'widget-link-face
!                       :button-prefix ""
!                       :button-suffix ""
!                       :mouse-face 'highlight
!                       )
                       buttons)
                 (setq links (cdr links))
                 (cond ((null links)

[-- Attachment #3: wid-edit-links-5.patch --]
[-- Type: text/plain, Size: 3274 bytes --]

Index: wid-edit.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/wid-edit.el,v
retrieving revision 1.157
diff -c -r1.157 wid-edit.el
*** wid-edit.el	17 Dec 2005 08:52:54 -0000	1.157
--- wid-edit.el	18 Dec 2005 02:45:39 -0000
***************
*** 124,129 ****
--- 124,136 ----
    :type 'face
    :group 'widget-faces)
  
+ (defface widget-link-face
+   `((((class color) (background light)) (:foreground "blue" :underline t))
+     (((class color) (background dark)) (:foreground "cyan" :underline t)))
+   "Face used to highlight attributes that are links."
+   :group 'custom-faces)
+ 
+ 
  ;; TTY gets special definitions here and in the next defface, because
  ;; the gray colors defined for other displays cause black text on a black
  ;; background, at least on light-background TTYs.
***************
*** 403,409 ****
      ;; We want to avoid the face with image buttons.
      (unless (widget-get widget :suppress-face)
        (overlay-put overlay 'face (widget-apply widget :button-face-get))
!       (overlay-put overlay 'mouse-face widget-mouse-face))
      (overlay-put overlay 'pointer 'hand)
      (overlay-put overlay 'follow-link follow-link)
      (overlay-put overlay 'help-echo help-echo)))
--- 410,417 ----
      ;; We want to avoid the face with image buttons.
      (unless (widget-get widget :suppress-face)
        (overlay-put overlay 'face (widget-apply widget :button-face-get))
!       ;;(overlay-put overlay 'mouse-face widget-mouse-face))
!       (overlay-put overlay 'mouse-face (widget-apply widget :mouse-face-get)))
      (overlay-put overlay 'pointer 'hand)
      (overlay-put overlay 'follow-link follow-link)
      (overlay-put overlay 'help-echo help-echo)))
***************
*** 1391,1396 ****
--- 1399,1405 ----
    :offset 0
    :format-handler 'widget-default-format-handler
    :button-face-get 'widget-default-button-face-get
+   :mouse-face-get 'widget-default-mouse-face-get
    :sample-face-get 'widget-default-sample-face-get
    :delete 'widget-default-delete
    :copy 'identity
***************
*** 1535,1540 ****
--- 1544,1557 ----
  	    (widget-apply parent :button-face-get)
  	  widget-button-face))))
  
+ (defun widget-default-mouse-face-get (widget)
+   ;; Use :mouse-face or widget-mouse-face
+   (or (widget-get widget :mouse-face)
+       (let ((parent (widget-get widget :parent)))
+ 	(if parent
+ 	    (widget-apply parent :mouse-face-get)
+ 	  widget-mouse-face))))
+ 
  (defun widget-default-sample-face-get (widget)
    ;; Use :sample-face.
    (widget-get widget :sample-face))
***************
*** 2893,2900 ****
  		(widget-create-child-and-convert
  		 widget 'visibility
  		 :help-echo "Show or hide rest of the documentation."
! 		 :on "Hide Rest"
! 		 :off "More"
  		 :always-active t
  		 :action 'widget-parent-action
  		 shown))
--- 2910,2922 ----
  		(widget-create-child-and-convert
  		 widget 'visibility
  		 :help-echo "Show or hide rest of the documentation."
! ;; 		 :on "Hide Rest"
! ;; 		 :off "More"
! 		 :on "<<"
! 		 :off "More..."
!                  :button-face 'widget-link-face
!                  :button-prefix ""
!                  :button-suffix ""
  		 :always-active t
  		 :action 'widget-parent-action
  		 shown))

[-- Attachment #4: Changelog-cus-edit-links --]
[-- Type: text/plain, Size: 485 bytes --]

2005-12-15  Lennart Borgman  <lennart.borgman.073@student.lu.se>

	* cus-edit.el (custom-buffer-create-internal): Rewording of
	header. Underlined links.
	(custom-add-parent-links): Underlined links.

	* wid-edit.el (widget-links-face): New face.
	(widget-specify-button): Use :mouse-face-get.
	(widget-default): Added :mouse-face-get.
	(widget-default-mouse-face-get): New function.
	(widget-documentation-string-value-create): Underlined face and
	new labels for Hide Rest and More.

[-- Attachment #5: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

These changes are good.  Please install them.  But note that one of your
strings includes "options" meaning variables and faces.  I've decided
to get rid of that usage.  For now, please put "settings" instead.
I might use "settings", and if not, it will be easy to change that.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

Juri Linkov wrote:

>>With the changes I'm suggesting you end up with the following preamble:
>>
>>  This is a customization buffer for group Emacs.
>>
>>  Editing an option value changes only the text in the buffer.  The
>>  State button can be used to set or save the option value.  Saving an
>>  option normally edits your init file.
>>
>>  See Help for more information.
>>    
>>
>
>I think your change makes this header more clear.  The only part that
>is still confusing is
>
>    The State button can be used to set or save the option value.
>
>I suspect that the first thing that a novice will do after reading this
>is to search the button with the name "State" in the customization buffer.
>  
>
I have attached a preliminary patch for this. The patch changes the text 
to something reminding of the text above. It also changes the links from 
a button-like style to underline. Please test the patch.

There is one thing that I have not found out how to change it: the 
"mouse over" face. It is gray whatever I do. If someone knows how to 
make a widget really display the highlight face then please tell me!

**** I am resending this. It did not reach the list directly because 
there were too many recipients before. Moderator, can you please just 
drop the message I sent before that is hold and is a duplication of this 
message.


[-- Attachment #2: cus-edit-links.patch --]
[-- Type: text/plain, Size: 5263 bytes --]

Index: cus-edit.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.243
diff -c -r1.243 cus-edit.el
*** cus-edit.el	4 Dec 2005 02:39:24 -0000	1.243
--- cus-edit.el	7 Dec 2005 22:32:29 -0000
***************
*** 1412,1445 ****
  		   'custom-button-pressed
  		 'custom-button-pressed-unraised))))
  
  (defun custom-buffer-create-internal (options &optional description)
    (custom-mode)
    (if custom-buffer-verbose-help
!       (progn
  	(widget-insert "This is a customization buffer")
  	(if description
  	    (widget-insert description))
  	(widget-insert (format ".
! %s show active fields; type RET or click mouse-1
! on an active field to invoke its action.  Editing an option value
! changes only the text in the buffer.  Invoke the State button to set or
! save the option value.  Saving an option normally edits your init file.
! Invoke "
  			       (if custom-raised-buttons
  				   "`Raised' buttons"
  				 "Square brackets")))
  	(widget-create 'info-link
! 		       :tag "Custom file"
! 		       "(emacs)Saving Customizations")
! 	(widget-insert
! 	 " for information on how to save in a different file.
! Invoke ")
! 	(widget-create 'info-link
! 		       :tag "Help"
  		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for general information.\n\n")
! 	(widget-insert "Operate on everything in this buffer:\n "))
      (widget-insert " "))
    (widget-create 'push-button
  		 :tag "Set for Current Session"
--- 1412,1471 ----
  		   'custom-button-pressed
  		 'custom-button-pressed-unraised))))
  
+ (defface custom-link-face
+   `((((class color) (background light)) (:foreground "blue" :underline t))
+     (((class color) (background dark)) (:foreground "cyan" :underline t)))
+   "Face used to highlight attributes that are links."
+   :group 'custom-faces)
+ 
+ 
  (defun custom-buffer-create-internal (options &optional description)
    (custom-mode)
    (if custom-buffer-verbose-help
!       (let (
!             (custom-file-txt "custom file")
!             (help-txt "help"))
!         ;;(put-text-property 0 (length custom-file-txt) 'mouse-face 'highlight custom-file-txt)
!         ;;(put-text-property 0 (length help-txt) 'mouse-face 'highlight help-txt)
  	(widget-insert "This is a customization buffer")
  	(if description
  	    (widget-insert description))
+ ;; %s show active fields; type RET or click mouse-1
+ ;; on an active field to invoke its action.  Editing an option value
+ ;; changes only the text in the buffer.  Invoke the State button to set or
+ ;; save the option value.  Saving an option normally edits your init file.
  	(widget-insert (format ".
! 
! Editing an option value changes only the text in the buffer.  The
! State button(s) next to the option(s) can be used to set or save
! the value. Saving an option normally edits your init file.
! 
! See "
  			       (if custom-raised-buttons
  				   "`Raised' buttons"
  				 "Square brackets")))
+ ;; 	(widget-create 'info-link
+ ;;                        :button-face 'custom-link-face
+ ;;                        :button-prefix ""
+ ;;                        :button-suffix ""
+ ;; 		       ;;:tag "Custom file"
+ ;; 		       :tag custom-file-txt
+ ;; 		       "(emacs)Saving Customizations")
+ ;; 	(widget-insert
+ ;; 	 " for information on how to save in a different file.\n\nSee ")
+ 
  	(widget-create 'info-link
!                        :button-face 'custom-link-face
!                        :button-prefix ""
!                        :button-suffix ""
!                        :mouse-face 'highlight
!                        :button-mouse-face 'highlight
! 		       ;;:tag "Help"
! 		       :tag help-txt
  		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for more information.\n\n")
! 	(widget-insert "Operate on all options in this buffer:\n "))
      (widget-insert " "))
    (widget-create 'push-button
  		 :tag "Set for Current Session"
***************
*** 2149,2154 ****
--- 2175,2183 ----
  		  (insert " ")
  		  (push (widget-create-child-and-convert
  			 widget 'custom-group-link
+                          :button-face 'custom-link-face
+                          :button-prefix ""
+                          :button-suffix ""
  			 :tag (custom-unlispify-tag-name symbol)
  			 symbol)
  			buttons)
***************
*** 2160,2166 ****
             (when links
               (insert "\nParent documentation: ")
               (while links
!                (push (widget-create-child-and-convert widget (car links))
                       buttons)
                 (setq links (cdr links))
                 (cond ((null links)
--- 2189,2200 ----
             (when links
               (insert "\nParent documentation: ")
               (while links
!                (push (widget-create-child-and-convert
!                       widget (car links)
!                       :button-face 'custom-link-face
!                       :button-prefix ""
!                       :button-suffix ""
!                       )
                       buttons)
                 (setq links (cdr links))
                 (cond ((null links)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: fancy-splash-screen customize group...

[Peter Whaite]

Juri Linkov <juri@jurta.org> wrote:

> I think your change makes this header more clear.  The only part that
> is still confusing is
> 
>     The State button can be used to set or save the option value.
> 
> I suspect that the first thing that a novice will do after reading this
> is to search the button with the name "State" in the customization
> buffer.

I'm probably being thick and missing something obvious, but dont you
think that after finding a button named "State" their first response
will be to click on it, in which case they will be presented with a
popup menu of actions?

There is at least one State button in every Customization buffer I
think.  Perhaps plural is better:

    The State buttons can be used to set or save option values.


-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

>From my previous message:

    Invoke Custom file for information on how to save in a different file.
    Invoke Help for general information.

  with "Custom" and "Help" being raised buttons,

I meant: with "Custom file" and "Help" being raised buttons.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Chong Yidong wrote:

>Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>  
>
>>Changing the look of this buttons to just underlined text would
>>improve things a lot.
>>    
>>
>
>Setting `custom-raised-buttons' to nil probably does what you want.
>  
>
I do not think so. I just want to change the look of these two buttons 
so that they appear as underlined text as the links in Info for example.

Help links (was: fancy-splash-screen customize group...)

[Juri Linkov]

>>>Changing the look of this buttons to just underlined text would
>>>improve things a lot.
>>
>>Setting `custom-raised-buttons' to nil probably does what you want.
>>
> I do not think so. I just want to change the look of these two buttons
> so that they appear as underlined text as the links in Info
> for example.

BTW, have you seen how customize buttons look on terminals?  They look
exactly as the links in the *info* buffer.  OTOH, links in the *Help*
buffer are not highlighted at all on ttys that don't support the
underline attribute.  I think links in the *Help* buffer should be
highlighted in blue like the links in the *info* and customization
buffers.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Help links

[Lennart Borgman]

Juri Linkov wrote:

>BTW, have you seen how customize buttons look on terminals?  They look
>exactly as the links in the *info* buffer.  OTOH, links in the *Help*
>buffer are not highlighted at all on ttys that don't support the
>underline attribute.  I think links in the *Help* buffer should be
>highlighted in blue like the links in the *info* and customization
>buffers.
>  
>
I agree. I think there should be an underlying link face from which the 
link faces in help, info and other buffers inherit.

Re: Help links

[Richard M. Stallman]

    I agree. I think there should be an underlying link face from which the 
    link faces in help, info and other buffers inherit.

That is too much of a change to consider at this point.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

	Invoke [Custom File] for information...
	Invoke [Help] for general information.

    Changing the look of this buttons to just underlined text would improve 
    things a lot. They are really just links. Changing "Invoke" to "See" 
    would make it less of a guessing game too.


    *** 2) When you click on the "Help" link (button) then the info node 
    "(emacs) Easy Customization" is displayed. I believe the 
    customize-apropos-* functions should be mentioned there, right after 
    "Groups" in the menu at the bottom.

These two changes are ok with me.  Could you post a patch?

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Richard M. Stallman wrote:

>	Invoke [Custom File] for information...
>	Invoke [Help] for general information.
>
>    Changing the look of this buttons to just underlined text would improve 
>    things a lot. They are really just links. Changing "Invoke" to "See" 
>    would make it less of a guessing game too.
>
>
>    *** 2) When you click on the "Help" link (button) then the info node 
>    "(emacs) Easy Customization" is displayed. I believe the 
>    customize-apropos-* functions should be mentioned there, right after 
>    "Groups" in the menu at the bottom.
>
>These two changes are ok with me.  Could you post a patch?
>  
>
I have posted patches for these two other messages:

** Underlined text:
    http://lists.gnu.org/archive/html/emacs-devel/2005-12/msg00343.html

** The apropose functions in info:
    Just posted this. Not available in the archives yet.

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Peter Whaite wrote:

   The documentation for 'customize-apropos' is under
   'Specific Customization' which doesn't exactly jump out at you.  How
   about renaming it to 'Finding Customizations',

That would be misleading, because only a small fraction of that node
is about _finding_ customizations.  Moreover the node does not discuss
what is intended to be the main way to browse and find options,
customize-browse.  On top of that, one should not make node name
changes lightly, because they may break existing links, some of them
in docs not included in the Emacs distribution (and which we hence can
not grep for).

   changing the info node header to 'Finding and Customizing Specific
   Items'?

Less bad, but still somewhat misleading.

   There is also no mention of customize-apropos-options,
   customize-apropos-groups, or customize-apropos-faces.  There should be.

That is easy to do.  I intend to send Richard a proposed set of
changes to man/custom.texi (mostly unrelated to the present
discussion) soon (probably tomorrow) and I can easily include a short
description of these three in `(emacs)Specific Customization'.

Sincerely,

Luc.

RE: fancy-splash-screen customize group...

[Drew Adams]

    > That's the point of linking Customize to apropos, so that you can
    > search for the option you want.

    At the very least the text at the top of the customize buffers should
    mention the apropos functions.

It should be added to the menu-bar Custom menu.

    You would also expect something about finding customizations to be in
    the info that is displayed when you press the 'Help' button, but there
    is nothing obvious....

    There is also no mention of customize-apropos-options,
    customize-apropos-groups, or customize-apropos-faces.  There should be.

I agree. Finding stuff quickly and easily is what it's all about. Customize
is a navigational nightmare, and the apropos commands help quite a bit.
Let's make them more visible (point out, add to menu,...).

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Drew Adams wrote:

>    > That's the point of linking Customize to apropos, so that you can
>    > search for the option you want.
>
>    At the very least the text at the top of the customize buffers should
>    mention the apropos functions.
>
>It should be added to the menu-bar Custom menu.
>  
>
Are they not there already? If you look in the menus under "Options - 
Customize Emacs" there are for entries for apropos searches:

    Settings Matching Regexps...
    Options Matching Regexps...
    Faces Matching Regexps...
    Groups Matching Regexps...

RE: fancy-splash-screen customize group...

[Drew Adams]

    >    > That's the point of linking Customize to apropos, so that you can
    >    > search for the option you want.
    >
    >    At the very least the text at the top of the customize
    >    buffers should mention the apropos functions.
    >
    >It should be added to the menu-bar Custom menu.

    Are they not there already? If you look in the menus under "Options -
    Customize Emacs" there are for entries for apropos searches:

        Settings Matching Regexps...
        Options Matching Regexps...
        Faces Matching Regexps...
        Groups Matching Regexps...

Menu-bar  _Custom_  menu - it is a major-mode menu that appears when you are
in a Customize buffer.  Users might not think to look in the separate
Options menu at that point.

Re: fancy-splash-screen customize group...

[Lennart Borgman]

Drew Adams wrote:

>    >It should be added to the menu-bar Custom menu.
>
>    Are they not there already? If you look in the menus under "Options -
>    Customize Emacs" there are for entries for apropos searches:
>
>        Settings Matching Regexps...
>        Options Matching Regexps...
>        Faces Matching Regexps...
>        Groups Matching Regexps...
>
>Menu-bar  _Custom_  menu - it is a major-mode menu that appears when you are
>in a Customize buffer.  Users might not think to look in the separate
>Options menu at that point.
>  
>
Good point.

Re: fancy-splash-screen customize group...

[Peter Whaite]

Drew Adams <drew.adams@oracle.com> wrote:
> Menu-bar  _Custom_  menu - it is a major-mode menu that appears when you are
> in a Customize buffer.  Users might not think to look in the separate
> Options menu at that point.

Yes it would be a good idea to have customize-apropos in Custom menu-bar
menus, but at the top level, not in a sub-menu.  Also it would be better
if the menu title was "Customize", not "Custom".

-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    I seem to have missed much of this discussion, but when I first ran
    across the customize beast I wished there was a 'Search' field or button
    in the customize buffer.

If there were such a button, what would it do?

Re: fancy-splash-screen customize group...

[Peter Whaite]

Richard M. Stallman <rms@gnu.org> wrote:
>     I seem to have missed much of this discussion, but when I first ran
>     across the customize beast I wished there was a 'Search' field or button
>     in the customize buffer.
> 
> If there were such a button, what would it do?

The same thing as the window menu:

   "Options/Customize Emacs/Settings Matching Regexp..."


-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    >     I seem to have missed much of this discussion, but when I first ran
    >     across the customize beast I wished there was a 'Search' field or button
    >     in the customize buffer.
    > 
    > If there were such a button, what would it do?

    The same thing as the window menu:

       "Options/Customize Emacs/Settings Matching Regexp..."

That meaning is not clear from the name.  With the name `Search' I
would expect it to search the buffer.

We could give it a different name.  But why is important for it
to have a button in the buffer, rather than the menu item under
Options/Customize Emacs, which exists now?

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    You would also expect something about finding customizations to be in
    the info that is displayed when you press the 'Help' button, but there
    is nothing obvious.  The documentation for 'customize-apropos' is under
    'Specific Customization' which doesn't exactly jump out at you.

I do not see any menu item called `Specific Customization',
so I don't understand.  apropos-variable is found in Find Options
by Name under the Help menu.

    There is also no mention of customize-apropos-options,
    customize-apropos-groups, or customize-apropos-faces.  There should be.

I tend to think these commands are not worth documenting,
and I doubt they are worth having.  

Re: fancy-splash-screen customize group...

[Peter Whaite]

Richard M. Stallman <rms@gnu.org> wrote:
>     You would also expect something about finding customizations to be in
>     the info that is displayed when you press the 'Help' button, but there
>     is nothing obvious.  The documentation for 'customize-apropos' is under
>     'Specific Customization' which doesn't exactly jump out at you.
> 
> I do not see any menu item called `Specific Customization',
> so I don't understand.

I meant an info node menu item, not the menu bar at the top of the
window.

When I press the Help button at the top of the customization buffer it
takes me to the Customization sub-node "Easy Customization".  Thats
where the `Specific Customization' is.

> apropos-variable is found in Find Options by Name under the Help menu.

I've always used 'customize-apropos', as I assumed it was more
appropriate for finding customizable options, faces, and groups.  It can
be found in the Options menu under `Customizing Emacs/Settings Matching
Regexp...'.

-- 
Peter Whaite

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    That's the point of linking Customize to apropos, so that you can
    search for the option you want.

I do not follow you.  Apropos is available now.  Why would yet another
box in the buffer help anyone?

RE: fancy-splash-screen customize group...

[Drew Adams]

           In my experience, the biggest problem with Customize is
           that it is very difficult to find a user option, because
           of the sheer number of customization groups and options.

    If it is simply due to the number of options that exist, I don't
    suppose anything can be done to improve that.  We're not going to
    get rid of a large fraction of the options.

    If someone has other ideas to make it easier to navigate thru Custom,
    we could entertain them.

Is that a call for such entertainment now? ;-)

I thought we were planning to discuss such matters _after_ the release. I
believe that the Customize UI could use a lot of work, including work along
these lines (reducing apparent complexity). But reworking the UI is
something that will require a fair amount of discussion (not to mention
implementation).

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

	If someone has other ideas to make it easier to navigate thru Custom,
	we could entertain them.

    Is that a call for such entertainment now? ;-)

It is probably better if we wait.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

    > I think this would only be marginally useful, not enough to justify
    > the added complexity, so my decision is not to add it.

    As for additional complexity, I implemented the idea for my own
    personal amusement, and it was easy.

When I talk about added complexity, that is not a matter of how hard
this is to implement.  It makes the custom buffer interface more
complex.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

Does this make it clearer?

Index: startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.390
diff -c -c -r1.390 startup.el
*** startup.el	22 Nov 2005 03:32:50 -0000	1.390
--- startup.el	4 Dec 2005 04:07:51 -0000
***************
*** 40,53 ****
    "Emacs start-up procedure."
    :group 'internal)
  
! (defcustom inhibit-startup-message nil
!   "*Non-nil inhibits the initial startup message.
  This is for use in your personal init file, once you are familiar
! with the contents of the startup message."
    :type 'boolean
    :group 'initialization)
  
! (defvaralias 'inhibit-splash-screen 'inhibit-startup-message)
  
  (defcustom inhibit-startup-echo-area-message nil
    "*Non-nil inhibits the initial startup echo area message.
--- 40,53 ----
    "Emacs start-up procedure."
    :group 'internal)
  
! (defcustom inhibit-splash-screen nil
!   "*Non-nil inhibits the startup screen.
  This is for use in your personal init file, once you are familiar
! with the contents of the startup screen."
    :type 'boolean
    :group 'initialization)
  
! (defvaralias 'inhibit-startup-message 'inhibit-splash-screen)
  
  (defcustom inhibit-startup-echo-area-message nil
    "*Non-nil inhibits the initial startup echo area message.

Re: fancy-splash-screen customize group...

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

> Does this make it clearer?

It would probably have made the difference required for myself
figuring this out before asking on the list.  So it is at least a
worthwhile improvement.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: fancy-splash-screen customize group...

[Luc Teirlinck]

Richard Stallman wrote:

   Does this make it clearer?

   Index: startup.el
   ===================================================================
   RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
   retrieving revision 1.390
   diff -c -c -r1.390 startup.el
   *** startup.el	22 Nov 2005 03:32:50 -0000	1.390
   --- startup.el	4 Dec 2005 04:07:51 -0000

What happened to this?  This was five days ago, just before this thread
started veering off on a wild and completely unrelated tangent.

I believe that actually more doc (or code) changes are needed.
Setting `inhibit-startup-message' to t seems to have as a consequence
that `initial-scratch-message' gets ignored: the *scratch* buffer
starts out empty, no matter what.  Is this intentional?  The
docstrings of neither `inhibit-startup-message' nor
`initial-scratch-message' mention this.  If the behavior would be
intentional, then I believe that both docstrings should mention this.
I was very surprised when I noticed.

Sincerely,

Luc.

Re: fancy-splash-screen customize group...

[Richard M. Stallman]

       retrieving revision 1.390
       diff -c -c -r1.390 startup.el
       *** startup.el	22 Nov 2005 03:32:50 -0000	1.390
       --- startup.el	4 Dec 2005 04:07:51 -0000

    What happened to this?

It is waiting to be installed.

    I believe that actually more doc (or code) changes are needed.
    Setting `inhibit-startup-message' to t seems to have as a consequence
    that `initial-scratch-message' gets ignored: the *scratch* buffer
    starts out empty, no matter what.  Is this intentional?

I suppose it was, but it is not important.  I don't think this
issue is worth worrying about--it is too small.

Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]

[Michael Kifer]

It's a mystery. I have no idea where this minibuffer frame is coming
from. It wasn't requested by ediff either.
In fact, I am pretty confident that this is an Emacs bug, not Ediff's.
If you try your routine:
emacs-cvs -Q -q --display :0.0 --eval '(make-frame-on-display "localhost:10.0")
through an ssh tunnel, as you described, but instead of using ediff try to
eval this:

(make-frame
   (list
   '(name . "FOOBAR")
   '(minibuffer . nil)
   '(user-position . t)
   '(vertical-scroll-bars . nil)
   '(menu-bar-lines . 0) 
   '(tool-bar-lines . 0)
   '(auto-lower . nil)
   '(auto-raise . t)
   '(visibility . nil)
   '(width . 1) '(height . 1)))

then when the dust settles you will see an unrequested minibuffer frame as
well. In fact, the FOOBAR frame doesn't show up at all, but only the
unrequested minibuffer.


	--michael  



> ------- Start of forwarded message -------
> X-Injected-Via-Gmane: http://gmane.org/
> To: emacs-devel@gnu.org
> From: Evil Boris <evilborisnet@netscape.net>
> Date: Sun, 04 Dec 2005 20:01:18 -0500
> X-Gmane-NNTP-Posting-Host: 207-38-193-43.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com
> Cancel-Lock: sha1:iL8AA0szOIxG1i5eS5q3drbE9pU=
> Subject: weird behavior of ediff with multiple displays
> Sender: emacs-devel-bounces+rms=gnu.org@gnu.org
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
> X-Spam-Level: 
> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
> 
> 
> Has anyone seen the following beahavior from ediff while running on
> multiple displays (not multiple screens of the same display):
> 
> While logged in remotely through SSH with X tunnelling turned on, I
> execute (details: Solaris 2.7, :0.0 is local display, localhost:10.0
> is SSH tunneled display):
> 
> emacs-cvs -Q -q --display :0.0 --eval '(make-frame-on-display "localhost:10.0")
> 
> Now in the resulting window that pops out on localhost:10.0 (remote
> display) I execute "M-x ediff RET file1 RET file2".  What I get on the
> localhost:10.0 display is the usual ediff control frame PLUS a weird
> wide and narrow (one or two lines tall) *Minibuf-0* frame (a dedicated
> minibuffer frame!?!?) that I definitely did not ask for.
> 
> I have seen this happen over many versions of CVS Emacs, with remote
> machine being a WinXP box with an X server, or a Linux box (ancient
> Mandrake, if it matters), so I am pretty sure it's an Emacs ediff
> "feature".
> 
> Interestingly, if I start emacs-cvs by hand with localhost:10.0
> display and then make-frame-on-display on :0.0, the effect
> disappears---it seems to matter which display was opened first.
> 
> Any ideas would be welcome.  How do I debug this?  Can anyone
> reproduce this?
> 
>           --Boris
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> ------- End of forwarded message -------
> 

Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]

[Richard M. Stallman]

    (make-frame
       (list
       '(name . "FOOBAR")
       '(minibuffer . nil)

That says this frame should not have its own minibuffer.
Emacs handles that by creating a separate minibuffer frame for
this frame to use.  That is the right thing for it to do.

Given that, can you determine whether there's a bug,
and whether it is in ediff?

Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]

[Michael Kifer]

rms wrote:
>
>     (make-frame
>        (list
>        '(name . "FOOBAR")
>        '(minibuffer . nil)))
> 
> That says this frame should not have its own minibuffer.
> Emacs handles that by creating a separate minibuffer frame for
> this frame to use.  That is the right thing for it to do.
> 
> Given that, can you determine whether there's a bug,
> and whether it is in ediff?
> 


I don't think this is the right thing to do in all cases.
This shouldn't happen when there is another frame that already has a
minibuffer. For some reason emacs adds the separate minibuffer frame
when it works over the ssh tunnel and displays frames on the local
machine (while running on a remote).
It seems that it gets confused about this situation.

This is the situation that I gave in my test case.

Run
emacs-cvs -Q -q --display :0.0 --eval '(make-frame-on-display "localhost:10.0")
through an ssh tunnel, as you described, but instead of using ediff try to
eval this:

(make-frame
   (list
   '(name . "FOOBAR")
   '(minibuffer . nil)
   '(user-position . t)
   '(vertical-scroll-bars . nil)
   '(menu-bar-lines . 0) 
   '(tool-bar-lines . 0)
   '(auto-lower . nil)
   '(auto-raise . t)
   '(visibility . nil)
   '(width . 1) '(height . 1)))

then when the dust settles you will see an unrequested minibuffer frame as
well.

Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]

[Richard M. Stallman]

    I don't think this is the right thing to do in all cases.
    This shouldn't happen when there is another frame that already has a
    minibuffer.

I don't like the idea of making one frame use another frame's
minibuffer, as a default.  If you want to do that, you can do it
explicitly, by specifying a different value for the `minibuffer' frame
parameter.  But the thing Emacs does automatically is create a separate
minibuffer frame.

I just commented out an incorrect change which would have altered
that.

    For some reason emacs adds the separate minibuffer frame
    when it works over the ssh tunnel and displays frames on the local
    machine (while running on a remote).

Perhaps the code that creates the separate minibuffer frame
needs to specify different arguments in that case.

The code is in make_frame_without_minibuffer.
Would someone like to suggest a patch to make it DTRT
in this case?

Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]

[Lőrentey Károly]

[-- Attachment #1.1: Type: text/plain, Size: 999 bytes --]

Richard Stallman <rms@gnu.org> writes:
>     I don't think this is the right thing to do in all cases.
>     This shouldn't happen when there is another frame that already has a
>     minibuffer.
>
> I don't like the idea of making one frame use another frame's
> minibuffer, as a default.  If you want to do that, you can do it
> explicitly, by specifying a different value for the `minibuffer' frame
> parameter.  But the thing Emacs does automatically is create a separate
> minibuffer frame.
>
> I just commented out an incorrect change which would have altered
> that.

When Emacs starts up under X, it automatically initializes
default-minibuffer-frame to be the initial frame.  The change I made
emulates this behaviour for display devices other than the initial
one.  Without this change, Emacs behaves inconsistently.  If the
automatic setting of default-minibuffer-frame is wrong, then I suggest
to remove its assignment from `frame-initialize' as well.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]

[Richard M. Stallman]

    When Emacs starts up under X, it automatically initializes
    default-minibuffer-frame to be the initial frame.

Sorry, I did not see that when I searched (because it's in Lisp).
I guess your change is ok.

Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]

[Michael Kifer]

If I specify that I want a frame without a minibuffer, I don't want emacs
to second-guess me and create a minibuffer-only frame that I didn't ask for.
This is a bad idea. If I wanted a separate minibuffer then I would have
said that I want it explicitly.


>     I don't think this is the right thing to do in all cases.
>     This shouldn't happen when there is another frame that already has a
>     minibuffer.
> 
> I don't like the idea of making one frame use another frame's
> minibuffer, as a default.  If you want to do that, you can do it
> explicitly, by specifying a different value for the `minibuffer' frame
> parameter.  But the thing Emacs does automatically is create a separate
> minibuffer frame.
> 
> I just commented out an incorrect change which would have altered
> that.
> 
>     For some reason emacs adds the separate minibuffer frame
>     when it works over the ssh tunnel and displays frames on the local
>     machine (while running on a remote).
> 
> Perhaps the code that creates the separate minibuffer frame
> needs to specify different arguments in that case.
> 
> The code is in make_frame_without_minibuffer.
> Would someone like to suggest a patch to make it DTRT
> in this case?
> 

Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]

[Lőrentey Károly]

[-- Attachment #1.1: Type: text/plain, Size: 1303 bytes --]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> If you try your routine:
> emacs-cvs -Q -q --display :0.0 --eval '(make-frame-on-display "localhost:10.0")
> through an ssh tunnel, as you described, but instead of using ediff try to
> eval this:
>
> (make-frame
>    (list
>    '(name . "FOOBAR")
>    '(minibuffer . nil)
>    '(user-position . t)
>    '(vertical-scroll-bars . nil)
>    '(menu-bar-lines . 0) 
>    '(tool-bar-lines . 0)
>    '(auto-lower . nil)
>    '(auto-raise . t)
>    '(visibility . nil)
>    '(width . 1) '(height . 1)))
>
> then when the dust settles you will see an unrequested minibuffer frame as
> well. In fact, the FOOBAR frame doesn't show up at all, but only the
> unrequested minibuffer.

The unexpected behaviour is the spurious creation of a minibuffer
frame.  It is created because Emacs does not initialize
`default-minibuffer-frame' when it creates the first frame with a
minibuffer on a new display device.  I fixed this bug in CVS.

Note that after evaluating the above expression, the FOOBAR frame is
present, but it is invisible, as requested in the visibility
parameter.  Note that a minibuffer frame is not created when the
visibility spec is removed---I don't know why that happens, but it
could be another bug.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

newsticker-start: Recursive laod error

[Sascha Wilde]

Starting CVS Emacs with 

emacs -Q -D

starting newsticker:

M-x newsticker-start

I get:

newsticker--set-customvar: Recursive load:
"/vol1/opt/cvs-emacs/share/emacs/22.0.50/lisp/net/newsticker.elc",
"/vol1/opt/cvs-emacs/share/emacs/22.0.50/lisp/net/newsticker.elc",
"/vol1/opt/cvs-emacs/share/emacs/22.0.50/lisp/net/newsticker.elc",
"/vol1/opt/cvs-emacs/share/emacs/22.0.50/lisp/net/newsticker.elc",
"/vol1/opt/cvs-emacs/share/emacs/22.0.50/lisp/net/newsticker.elc"

cheers
sascha
-- 
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.

Re: newsticker-start: Recursive laod error

[Xavier Maillard]

   From: Sascha Wilde <wilde@sha-bang.de>

   Starting CVS Emacs with 

   emacs -Q -D

   starting newsticker:

   M-x newsticker-start

It works like a charm here on Debian SID (Emacs-snapshot package).

Xavier

Re: newsticker-start: Recursive laod error

[Lennart Borgman]

Xavier Maillard wrote:

>   From: Sascha Wilde <wilde@sha-bang.de>
>
>   Starting CVS Emacs with 
>
>   emacs -Q -D
>
>   starting newsticker:
>
>   M-x newsticker-start
>
>It works like a charm here on Debian SID (Emacs-snapshot package).
>
>Xavier
>  
>
On w32, todays CVS I get:

Loading newsticker...
Loading subst-ksc...done
Loading subst-gb2312...done
Loading subst-big5...done
Loading subst-jis...done
Loading newsticker... [3 times]
newsticker--set-customvar: Recursive load: 
"d:/emacs/051210/emacs/lisp/net/newsticker.elc", 
"d:/emacs/051210/emacs/lisp/net/newsticker.elc", 
"d:/emacs/051210/emacs/lisp/net/newsticker.elc", 
"d:/emacs/051210/emacs/lisp/net/newsticker.elc", 
"d:/emacs/051210/emacs/lisp/net/newsticker.elc"

Re: newsticker-start: Recursive laod error

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Sat, 2005 Dec 10  11:04 UTC
GNU Emacs 22.0.50.51 (i686-pc-linux-gnu, GTK+ Version 2.6.10)
started with

     ./emacs/src/emacs -Q -D

Recursive load error with newsticker-start:

    Loading newsticker... [3 times]
    newsticker--set-customvar: Recursive load:
    "/usr/local/src/emacs/lisp/net/newsticker.elc",
    "/usr/local/src/emacs/lisp/net/newsticker.elc",
    "/usr/local/src/emacs/lisp/net/newsticker.elc",
    "/usr/local/src/emacs/lisp/net/newsticker.elc",
    "/usr/local/src/emacs/lisp/net/newsticker.elc"

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: newsticker-start: Recursive laod error

[Richard M. Stallman]

    On w32, todays CVS I get:

    Loading newsticker...
    Loading subst-ksc...done
    Loading subst-gb2312...done
    Loading subst-big5...done
    Loading subst-jis...done
    Loading newsticker... [3 times]
    newsticker--set-customvar: Recursive load: 
    "d:/emacs/051210/emacs/lisp/net/newsticker.elc", 
    "d:/emacs/051210/emacs/lisp/net/newsticker.elc", 

Since it fails for you, could you debug it?

Re: newsticker-start: Recursive laod error

[Xavier Maillard]

Well I finally discovered why it did not fail here. That was due
to I was using version 1.5.

I just apt-get remove Emacs-goodies-el (debian package), deleted
all newsticker.el laying around and finally restarted Emacs.

With the version shipped in Emacs-snapshot (aka CVS), I have this:

Debugger entered--Lisp error: (error "Recursive load" "/usr/share/emacs/22.0.50/lisp/net/newsticker.elc" "/usr/share/emacs/22.0.50/lisp/net/newsticker.elc" "/usr/share/emacs/22.0.50/lisp/net/newsticker.elc" "/usr/share/emacs/22.0.50/lisp/net/newsticker.elc" "/usr/share/emacs/22.0.50/lisp/net/newsticker.elc")
  newsticker-running-p()
  newsticker--set-customvar(newsticker-hide-immortal-items-in-echo-area t)
  custom-initialize-reset(newsticker-hide-immortal-items-in-echo-area t)
  custom-declare-variable(newsticker-hide-immortal-items-in-echo-area t ("/usr/share/emacs/22.0.50/lisp/net/newsticker.elc" . 21378) :type boolean :set newsticker--set-customvar :group newsticker-ticker)
  newsticker-running-p()
  newsticker--set-customvar(newsticker-display-interval 0.3)
  custom-initialize-reset(newsticker-display-interval 0.3)
  custom-declare-variable(newsticker-display-interval 0.3 ("/usr/share/emacs/22.0.50/lisp/net/newsticker.elc" . 20385) :type number :set newsticker--set-customvar :group newsticker-ticker)
  newsticker-running-p()
  newsticker--set-customvar(newsticker-retrieval-interval 3600)
  custom-initialize-reset(newsticker-retrieval-interval 3600)
  custom-declare-variable(newsticker-retrieval-interval 3600 ("/usr/share/emacs/22.0.50/lisp/net/newsticker.elc" . 7521) :type (choice :tag "Interval" (const :tag "No automatic retrieval" 0) (const :tag "Hourly" 3600) (const :tag "Daily" 86400) (const :tag "Weekly" 604800) (integer :tag "Interval")) :set newsticker--set-customvar :group newsticker-feed)
  newsticker-running-p()
  newsticker--set-customvar(newsticker-url-list-defaults (("Emacs Wiki" "http://www.emacswiki.org/cgi-bin/wiki.pl?action=rss" nil 3600)))
  custom-initialize-reset(newsticker-url-list-defaults (quote (("Emacs Wiki" "http://www.emacswiki.org/cgi-bin/wiki.pl?action=rss" nil 3600))))
  custom-declare-variable(newsticker-url-list-defaults (quote (("Emacs Wiki" "http://www.emacswiki.org/cgi-bin/wiki.pl?action=rss" nil 3600))) ("/usr/share/emacs/22.0.50/lisp/net/newsticker.elc" . 4526) :type (set (list :tag "CNET News.com" (const "CNET News.com") (const "http://export.cnet.com/export/feeds/news/rss/1,11176,,00.xml")) (list :tag "Debian Security Advisories" (const "Debian Security Advisories") (const "http://www.debian.org/security/dsa.en.rdf")) (list :tag "Debian Security Advisories - Long format" (const "Debian Security Advisories - Long format") (const "http://www.debian.org/security/dsa-long.en.rdf")) (list :tag "Emacs Wiki" (const "Emacs Wiki") (const "http://www.emacswiki.org/cgi-bin/wiki.pl?action=rss") (const nil) (const 3600)) (list :tag "Freshmeat.net" (const "Freshmeat.net") (const "http://freshmeat.net/backend/fm.rdf")) (list :tag "Kuro5hin.org" (const "Kuro5
 hin.org") (const "http://www.kuro5hin.org/backend.rdf")) (list :tag "LWN (Linux Weekly News)" (const "LWN (Linux Weekly News)") (const "http://lwn.net/headlines/rss")) (list :tag "NewsForge" (const "NewsForge") (const "http://newsforge.com/index.rss")) (list :tag "NY Times: Technology" (const "NY Times: Technology") (const "http://partners.userland.com/nytRss/technology.xml")) (list :tag "NY Times" (const "NY Times") (const "http://partners.userland.com/nytRss/nytHomepage.xml")) (list :tag "Quote of the day" (const "Quote of the day") (const "http://www.quotationspage.com/data/qotd.rss") (const "07:00") (const 86400)) (list :tag "The Register" (const "The Register") (const "http://www.theregister.co.uk/tonys/slashdot.rdf")) (list :tag "slashdot" (const "slashdot") (const "http://slashdot.org/index.rss") (const nil) (const 3600)) (list :tag "Wired News" (const "Wired News") (const "http
 ://www.wired.com/news_drop/netcenter/netcenter.rdf")) (list :tag "Heise News (german)" (const "Heise News (german)") (const "http://www.heise.de/newsticker/heise.rdf")) (list :tag "Tagesschau (german)" (const "Tagesschau (german)") (const "http://www.tagesschau.de/newsticker.rdf") (const nil) (const 1800)) (list :tag "Telepolis (german)" (const "Telepolis (german)") (const "http://www.heise.de/tp/news.rdf"))) :set newsticker--set-customvar :group newsticker-feed)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

Voila.

Re: newsticker-start: Recursive laod error

[Richard M. Stallman]

Thanks for investigating. Does this fix it?

*** newsticker.el	05 Nov 2005 09:36:16 -0500	1.8
--- newsticker.el	11 Dec 2005 13:41:44 -0500	
***************
*** 392,397 ****
--- 392,423 ----
  (defvar w3m-minor-mode-map)
  
  ;; ======================================================================
+ ;;; Newsticker status
+ ;; ======================================================================
+ 
+ (defvar newsticker--retrieval-timer-list nil
+   "List of timers for news retrieval.
+ This is an alist, each element consisting of (feed-name . timer)")
+ 
+ (defvar newsticker--display-timer nil
+   "Timer for newsticker display.")
+ 
+ ;;;###autoload
+ (defun newsticker-running-p ()
+   "Check whether newsticker is running.
+ Return t if newsticker is running, nil otherwise.  Newsticker is
+ considered to be running if the newsticker timer list is not empty."
+   (> (length newsticker--retrieval-timer-list) 0))
+ 
+ ;;;###autoload
+ (defun newsticker-ticker-running-p ()
+   "Check whether newsticker's actual ticker is running.
+ Return t if ticker is running, nil otherwise.  Newsticker is
+ considered to be running if the newsticker timer list is not
+ empty."
+   (timerp newsticker--display-timer))
+ 
+ ;; ======================================================================
  ;;; Customizables
  ;; ======================================================================
  (defgroup newsticker nil
***************
*** 1188,1198 ****
  ;; ======================================================================
  ;;; Internal variables
  ;; ======================================================================
- (defvar newsticker--display-timer nil
-   "Timer for newsticker display.")
- (defvar newsticker--retrieval-timer-list nil
-   "List of timers for news retrieval.
- This is an alist, each element consisting of (feed-name . timer)")
  (defvar newsticker--item-list nil
    "List of newsticker items.")
  (defvar newsticker--item-position 0
--- 1214,1219 ----
***************
*** 3077,3100 ****
          (newsticker--buffer-beginning-of-item)
          (let ((age (get-text-property (point) 'nt-age)))
            (and (memq  age '(new old obsolete)) t)))))
- 
- ;; ======================================================================
- ;;; Newsticker status
- ;; ======================================================================
- ;;;###autoload
- (defun newsticker-running-p ()
-   "Check whether newsticker is running.
- Return t if newsticker is running, nil otherwise.  Newsticker is
- considered to be running if the newsticker timer list is not empty."
-   (> (length newsticker--retrieval-timer-list) 0))
- 
- ;;;###autoload
- (defun newsticker-ticker-running-p ()
-   "Check whether newsticker's actual ticker is running.
- Return t if ticker is running, nil otherwise.  Newsticker is
- considered to be running if the newsticker timer list is not
- empty."
-   (timerp newsticker--display-timer))
  
  ;; ======================================================================
  ;;; local stuff
--- 3098,3103 ----

Re: newsticker-start: Recursive laod error

[Xavier Maillard]

   Thanks for investigating. Does this fix it?

That works beautifuly for me.

Thank you

Re: newsticker-start: Recursive laod error

[Sascha Wilde]

"Richard M. Stallman" <rms@gnu.org> wrote:

> Thanks for investigating. Does this fix it?

Your patch fixed it for me, too.  Thanks!

sascha
-- 
Sascha Wilde : VI is to EMACS as masturbation is to making love:
             : effective and always available but probably not your
             : first choice...

Re: newsticker-start: Recursive laod error

[Lennart Borgman]

Sascha Wilde wrote:

>"Richard M. Stallman" <rms@gnu.org> wrote:
>
>  
>
>>Thanks for investigating. Does this fix it?
>>    
>>
>
>Your patch fixed it for me, too.  Thanks!
>
>sascha
>  
>
I can not for some reason apply the patch. I saved it to a file named 
newsticker.el.patch and then I do

    /cygdrive/d/ecvs/bld/emacs/lisp/net >   patch < newsticker.el.patch
   patching file newsticker.el
   Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 340

The patch file looks like this (middle part removed):

 >>>>>>>>>>>>>>>>>>>>
*** newsticker.el       05 Nov 2005 09:36:16 -0500      1.8
--- newsticker.el       11 Dec 2005 13:41:44 -0500     
***************
*** 392,397 ****
--- 392,423 ----
  (defvar w3m-minor-mode-map)
....
  ;; ======================================================================
  ;;; local stuff
--- 3098,3103 ----
<<<<<<<<<<<<<<<<<<

I took the patch from 
http://lists.gnu.org/archive/html/emacs-devel/2005-12/msg00643.html
Am I doing something wrong here or?

Re: newsticker-start: Recursive laod error

[Sascha Wilde]

Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Sascha Wilde wrote:
>
>>"Richard M. Stallman" <rms@gnu.org> wrote:
>>>Thanks for investigating. Does this fix it?

> I can not for some reason apply the patch. I saved it to a file named
> newsticker.el.patch and then I do
>
>     /cygdrive/d/ecvs/bld/emacs/lisp/net >   patch < newsticker.el.patch
>    patching file newsticker.el
>    Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 340

This seems to be a problem with your (cygwin?) patch programm, not
with the patch itself.

cheers
sascha
-- 
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.

Re: newsticker-start: Recursive laod error

[Xavier Maillard]

   From: Lennart Borgman <lennart.borgman.073@student.lu.se>
   Cc: rms@gnu.org, zedek@gnu-rox.org, emacs-devel@gnu.org

   Sascha Wilde wrote:

   >"Richard M. Stallman" <rms@gnu.org> wrote:
   >
   >  
   >
   >>Thanks for investigating. Does this fix it?
   >>    
   >>
   >
   >Your patch fixed it for me, too.  Thanks!
   >
   >sascha
   >  
   >
   I can not for some reason apply the patch. I saved it to a file named 
   newsticker.el.patch and then I do

       /cygdrive/d/ecvs/bld/emacs/lisp/net >   patch < newsticker.el.patch

I did

Patch -p0 < newsticker.el.diff here and it worked this way.

Hope that helps.

Xavier

Re: newsticker-start: Recursive laod error

[Lennart Borgman]

Xavier Maillard wrote:

>    I can not for some reason apply the patch. I saved it to a file named 
>   newsticker.el.patch and then I do
>
>       /cygdrive/d/ecvs/bld/emacs/lisp/net >   patch < newsticker.el.patch
>
>I did
>
>Patch -p0 < newsticker.el.diff here and it worked this way.
>
>Hope that helps.
>
>Xavier
>
Thanks for telling me. It turned out that the reason that it did not 
work was a problem with line endings. For some reason patch does not 
understand different line endings types in patch file and the patched 
files correctly. (This is very annoying IMHO and wastes a lot of time.)

Re: newsticker-start: Recursive laod error

[Eli Zaretskii]

> Date: Thu, 15 Dec 2005 18:28:45 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org
> 
> It turned out that the reason that it did not work was a problem
> with line endings. For some reason patch does not understand
> different line endings types in patch file and the patched files
> correctly.

It does, if you use the right port of Patch.

Re: newsticker-start: Recursive laod error

[Sascha Wilde]

Sascha Wilde <wilde@sha-bang.de> wrote:

> "Richard M. Stallman" <rms@gnu.org> wrote:
>
>> Thanks for investigating. Does this fix it?
>
> Your patch fixed it for me, too.  Thanks!

Since it seems to work fine, could you consider commiting this patch?

sascha
-- 
Sascha Wilde : "Lies, was ich meine, nicht, was ich schreibe."
             : (Urs Traenkner in de.alt.admin)

Re: newsticker-start: Recursive laod error

[Lennart Borgman]

Sascha Wilde wrote:

>Sascha Wilde <wilde@sha-bang.de> wrote:
>
>  
>
>>"Richard M. Stallman" <rms@gnu.org> wrote:
>>
>>    
>>
>>>Thanks for investigating. Does this fix it?
>>>      
>>>
>>Your patch fixed it for me, too.  Thanks!
>>    
>>
>
>Since it seems to work fine, could you consider commiting this patch?
>
>sascha
>  
>
Did I remember to say that it works for me on w32 too? It does.

Re: newsticker-start: Recursive laod error

[Richard M. Stallman]

    Since it seems to work fine, could you consider commiting this patch?

I will.  I was waiting for confirmation that it worked, and since
then I have not had time.  But I will.

Re: newsticker-start: Recursive laod error

[Eli Zaretskii]

> From: Xavier Maillard <zedek@gnu-rox.org>
> Date: Sat, 10 Dec 2005 09:55:02 +0100
> Cc: emacs-devel@gnu.org
> 
>    From: Sascha Wilde <wilde@sha-bang.de>
> 
>    Starting CVS Emacs with 
> 
>    emacs -Q -D
> 
>    starting newsticker:
> 
>    M-x newsticker-start
> 
> It works like a charm here on Debian SID (Emacs-snapshot package).

What version of Emacs-snapshot is that (i.e., on which date was the
CVS tree snapshotted)?  With today's CVS, I see this problem on both
Debian GNU/Linux and on MS-Windows.  Here's the full backtrace that I
get on a Debian box if I bind debug-on-error to t:

Debugger entered--Lisp error: (error "Recursive load" "/home/e/eliz/emacs.cvs/e\
macs/lisp/net/newsticker.elc" "/home/e/eliz/emacs.cvs/emacs/lisp/net/newsticker\
.elc" "/home/e/eliz/emacs.cvs/emacs/lisp/net/newsticker.elc" "/home/e/eliz/emac\
s.cvs/emacs/lisp/net/newsticker.elc" "/home/e/eliz/emacs.cvs/emacs/lisp/net/new\
sticker.elc")
  newsticker-running-p()
  newsticker--set-customvar(newsticker-display-interval 0.3)
  custom-initialize-reset(newsticker-display-interval 0.3)
  custom-declare-variable(newsticker-display-interval 0.3 ("/home/e/eliz/emacs.\
cvs/emacs/lisp/net/newsticker.elc" . 20340) :type number :set newsticker--set-c\
ustomvar :group newsticker-ticker)
  newsticker-running-p()
  newsticker--set-customvar(newsticker-retrieval-interval 3600)
  custom-initialize-reset(newsticker-retrieval-interval 3600)
  custom-declare-variable(newsticker-retrieval-interval 3600 ("/home/e/eliz/ema\
cs.cvs/emacs/lisp/net/newsticker.elc" . 7476) :type (choice :tag "Interval" (co\
nst :tag "No automatic retrieval" 0) (const :tag "Hourly" 3600) (const :tag "Da\
ily" 86400) (const :tag "Weekly" 604800) (integer :tag "Interval")) :set newsti\
cker--set-customvar :group newsticker-feed)
  newsticker-running-p()
  newsticker--set-customvar(newsticker-url-list nil)
  custom-initialize-reset(newsticker-url-list nil)
  custom-declare-variable(newsticker-url-list nil ("/home/e/eliz/emacs.cvs/emac\
s/lisp/net/newsticker.elc" . 4994) :type (repeat (list :tag "News feed" (string\
 :tag "Label") (string :tag "URI") (choice :tag "Start" ... ...) (choice :tag "\
Interval" ... ... ... ... ...) (choice :tag "Wget Arguments" ... ...))) :set ne\
wsticker--set-customvar :group newsticker-feed)
  newsticker-running-p()
  newsticker-running-p()
  newsticker--set-customvar(newsticker-url-list-defaults (("Emacs Wiki" "http:/\
/www.emacswiki.org/cgi-bin/wiki.pl?action=rss" nil 3600)))
  custom-initialize-reset(newsticker-url-list-defaults (quote (("Emacs Wiki" "h\
ttp://www.emacswiki.org/cgi-bin/wiki.pl?action=rss" nil 3600))))
  custom-declare-variable(newsticker-url-list-defaults (quote (("Emacs Wiki" "h\
ttp://www.emacswiki.org/cgi-bin/wiki.pl?action=rss" nil 3600))) ("/home/e/eliz/\
emacs.cvs/emacs/lisp/net/newsticker.elc" . 4481) :type (set (list :tag "CNET Ne\
ws.com" (const "CNET News.com") (const "http://export.cnet.com/export/feeds/new\
s/rss/1,11176,,00.xml")) (list :tag "Debian Security Advisories" (const "Debian\
 Security Advisories") (const "http://www.debian.org/security/dsa.en.rdf")) (li\
st :tag "Debian Security Advisories - Long format" (const "Debian Security Advi\
sories - Long format") (const "http://www.debian.org/security/dsa-long.en.rdf")\
) (list :tag "Emacs Wiki" (const "Emacs Wiki") (const "http://www.emacswiki.org\
/cgi-bin/wiki.pl?action=rss") (const nil) (const 3600)) (list :tag "Freshmeat.n\
et" (const "Freshmeat.net") (const "http://freshmeat.net/backend/fm.rdf")) (lis\
t :tag "Kuro5hin.org" (const "Kuro5hin.org") (const "http://www.kuro5hin.org/ba\
ckend.rdf")) (list :tag "LWN (Linux Weekly News)" (const "LWN (Linux Weekly New\s)") (const "http://lwn.net/headlines/rss")) (list :tag "NewsForge" (const "New\sForge") (const "http://newsforge.com/index.rss")) (list :tag "NY Times: Techno\
logy" (const "NY Times: Technology") (const "http://partners.userland.com/nytRs\
s/technology.xml")) (list :tag "NY Times" (const "NY Times") (const "http://par\
tners.userland.com/nytRss/nytHomepage.xml")) (list :tag "Quote of the day" (con\
st "Quote of the day") (const "http://www.quotationspage.com/data/qotd.rss") (c\
onst "07:00") (const 86400)) (list :tag "The Register" (const "The Register") (\
const "http://www.theregister.co.uk/tonys/slashdot.rdf")) (list :tag "slashdot"\
 (const "slashdot") (const "http://slashdot.org/index.rss") (const nil) (const \
3600)) (list :tag "Wired News" (const "Wired News") (const "http://www.wired.co\
m/news_drop/netcenter/netcenter.rdf")) (list :tag "Heise News (german)" (const \
"Heise News (german)") (const "http://www.heise.de/newsticker/heise.rdf")) (lis\
t :tag "Tagesschau (german)" (const "Tagesschau (german)") (const "http://www.t\
agesschau.de/newsticker.rdf") (const nil) (const 1800)) (list :tag "Telepolis (\
german)" (const "Telepolis (german)") (const "http://www.heise.de/tp/news.rdf")\
)) :set newsticker--set-customvar :group newsticker-feed)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

Re: newsticker-start: Recursive laod error

[Ulf Jasper]

I've had the recursive load error about two weeks ago with the my own CVS
snapshot.  (It also occured with Debian's emacs-snapshot.)  Removing
loaddefs.el and building Emacs from scratch fixed it (i.e. something like
make distclean; rm lisp/loaddefs.el; make bootstrap).

It looks like this is not a newsticker but an autoload or makefile problem.

ulf

Re: newsticker-start: Recursive laod error

[Eli Zaretskii]

> Date: Sat, 10 Dec 2005 15:28:40 +0100
> Cc: zedek@gnu-rox.org, wilde@sha-bang.de, emacs-devel@gnu.org
> From: Ulf Jasper <ulf.jasper@web.de>
> 
> I've had the recursive load error about two weeks ago with the my own CVS
> snapshot.  (It also occured with Debian's emacs-snapshot.)  Removing
> loaddefs.el and building Emacs from scratch fixed it (i.e. something like
> make distclean; rm lisp/loaddefs.el; make bootstrap).

Not this time: I did a full bootstrap on the Debian box to build
today's CVS, and the problem is still there.

Re: newsticker-start: Recursive laod error

[Lennart Borgman]

Eli Zaretskii wrote:

>>Date: Sat, 10 Dec 2005 15:28:40 +0100
>>Cc: zedek@gnu-rox.org, wilde@sha-bang.de, emacs-devel@gnu.org
>>From: Ulf Jasper <ulf.jasper@web.de>
>>
>>I've had the recursive load error about two weeks ago with the my own CVS
>>snapshot.  (It also occured with Debian's emacs-snapshot.)  Removing
>>loaddefs.el and building Emacs from scratch fixed it (i.e. something like
>>make distclean; rm lisp/loaddefs.el; make bootstrap).
>>    
>>
>
>Not this time: I did a full bootstrap on the Debian box to build
>today's CVS, and the problem is still there.
>  
>
And I have done a full bootstrap on w32 (as I always do) and I also 
still see the problem.

Re: newsticker-start: Recursive laod error

[Richard M. Stallman]

    >Not this time: I did a full bootstrap on the Debian box to build
    >today's CVS, and the problem is still there.
    >  
    >
    And I have done a full bootstrap on w32 (as I always do) and I also 
    still see the problem.

Can one of you debug it, then?
More people saying they see it won't fix it.
One person debugging it will fix it.

Re: newsticker-start: Recursive laod error

[Xavier Maillard]

   From: Eli Zaretskii <eliz@gnu.org>
   Cc: wilde@sha-bang.de, emacs-devel@gnu.org

   > From: Xavier Maillard <zedek@gnu-rox.org>
   > Date: Sat, 10 Dec 2005 09:55:02 +0100
   > Cc: emacs-devel@gnu.org
   > 
   >    From: Sascha Wilde <wilde@sha-bang.de>
   > 
   >    Starting CVS Emacs with 
   > 
   >    emacs -Q -D
   > 
   >    starting newsticker:
   > 
   >    M-x newsticker-start
   > 
   > It works like a charm here on Debian SID (Emacs-snapshot package).

   What version of Emacs-snapshot is that (i.e., on which date was the
   CVS tree snapshotted)?  With today's CVS, I see this problem on both
   Debian GNU/Linux and on MS-Windows.  Here's the full backtrace that I
   get on a Debian box if I bind debug-on-error to t:

Here it is:

ii  emacs-snapshot  20051207-1

Hope that helps.

Xavier

Re: newsticker-start: Recursive laod error

[Romain Francoise]

Removing the autoload on `newsticker-running-p' fixes it for me: it's
called for each customizable variable via `newsticker--set-customvar',
and Emacs tries to autoload the file for each variable, apparently.

Why is `newsticker-running-p' autoloaded?  If newsticker.el isn't
loaded, it can't possibly be running!

Index: lisp/net/newsticker.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/net/newsticker.el,v
retrieving revision 1.8
diff -c -r1.8 newsticker.el
*** lisp/net/newsticker.el	4 Nov 2005 15:15:39 -0000	1.8
--- lisp/net/newsticker.el	11 Dec 2005 11:32:38 -0000
***************
*** 3081,3094 ****
  ;; ======================================================================
  ;;; Newsticker status
  ;; ======================================================================
- ;;;###autoload
  (defun newsticker-running-p ()
    "Check whether newsticker is running.
  Return t if newsticker is running, nil otherwise.  Newsticker is
  considered to be running if the newsticker timer list is not empty."
    (> (length newsticker--retrieval-timer-list) 0))
  
- ;;;###autoload
  (defun newsticker-ticker-running-p ()
    "Check whether newsticker's actual ticker is running.
  Return t if ticker is running, nil otherwise.  Newsticker is
--- 3081,3092 ----

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: newsticker-start: Recursive laod error

[Ulf Jasper]

On Sunday, 11 December 2005, 12:40 +0100, Romain Francoise wrote:
> Why is `newsticker-running-p' autoloaded?  If newsticker.el isn't
> loaded, it can't possibly be running!

`newsticker-running-p' is supposed to be a "public" function.  (I remember
that somebody was asking for that functionality.)  It is autoloaded for
convenience.  If it wasn't autoloaded you'd have to check whether
newsticker is loaded before checking whether it is running.

Re: newsticker-start: Recursive laod error

[Thien-Thi Nguyen]

Ulf Jasper <ulf.jasper@web.de> writes:

> `newsticker-running-p' is supposed to be a "public" function.
> (I remember that somebody was asking for that functionality.)
> It is autoloaded for convenience.  If it wasn't autoloaded you'd
> have to check whether newsticker is loaded before checking
> whether it is running.

as a predicate,

  (= 0 (length LIST)) === LIST

this means you can elide `newsticker-running-p' entirely,
and put an autoload cookie on the variable.  the value before
loading (i.e., default value) is nil.

this allows state to be checked (with consistent results ;-)
whether or not newsticker.el is loaded, and reduces the number
of trivial functions by one.  (incf elegance)!

thi

Re: newsticker-start: Recursive laod error

[Thien-Thi Nguyen]

Thien-Thi Nguyen <ttn@gnu.org> writes:

>   (= 0 (length LIST)) === LIST

sorry, this is wrong.  it should read:

  (< 0 (length LIST)) === LIST

that is, an empty list has length 0, and is equivalent to nil.
anyway, the (valid) rest of the message relies on this property.

thi

Re: newsticker-start: Recursive laod error

[Stefan Monnier]

> sorry, this is wrong.  it should read:

>   (< 0 (length LIST)) === LIST

Unless LIST is a string, of course,


        Stefan

Re: newsticker-start: Recursive laod error

[Thien-Thi Nguyen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > sorry, this is wrong.  it should read:
> 
> >   (< 0 (length LIST)) === LIST
> 
> Unless LIST is a string, of course,

true, the property does not hold for strings or vectors.
i suppose if this state were to eventually be implemented
using those data types, then there would exist a problem
that a trivial function could be used to abstract away.
until that happens, occam sez: zonk the -p!

thi

Re: newsticker-start: Recursive laod error

[Stefan Monnier]

>> >   (< 0 (length LIST)) === LIST
>> Unless LIST is a string, of course,
> true, the property does not hold for strings or vectors.
[...]
> until that happens, occam sez: zonk the -p!

100% agreement, I was just nitpicking and wasting people's time.


        Stefan

Re: newsticker-start: Recursive laod error

[Ulf Jasper]

On Tuesday, 13 December 2005, 16:40 -0500, Stefan Monnier wrote:
> >> >   (< 0 (length LIST)) === LIST
> >> Unless LIST is a string, of course,
> > true, the property does not hold for strings or vectors.
> [...]
> > until that happens, occam sez: zonk the -p!

That Occam guy is an old friend of mine... but could someone please explain
the "(< 0 (length LIST)) === LIST" part to newbie me?

ulf

Re: newsticker-start: Recursive laod error

[Tomas Zerolo]

[-- Attachment #1.1: Type: text/plain, Size: 742 bytes --]

On Wed, Dec 14, 2005 at 08:22:29PM +0100, Ulf Jasper wrote:

[...]

> That Occam guy is an old friend of mine... but could someone please explain
> the "(< 0 (length LIST)) === LIST" part to newbie me?

I'm guessing you are baffled by the === part. This is not Lisp, but meta-lisp
;-) meaning roughly "is equivalent to". So that reads

    (< 0 (length LIST)) is equivalent to LIST

which, of course only has meaning in some contextx (and in some others
it's even false, as has been pointed out in this thread).

I.e., instead of writing

    (if (< 0 (length LIST))
       ...)

you may write

    (if LIST
       ...)

*provided you know LIST is indeed a list* (and not e.g. a string).

Ah, Thien-Thi's conciseness... :-)

Regards
-- tomas

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: newsticker-start: Recursive laod error

[Thien-Thi Nguyen]

Ulf Jasper <ulf.jasper@web.de> writes:

> the "(< 0 (length LIST)) === LIST" part to newbie me?

the "===" means "equivalent in a predicate context" here (sorry for the
confusion; this is ttn-post-C2H5OH notation :-).  i suppose i should have
continued to quote "in a predicate", which was at the beginning of my original
message -- that is the key to this thread.

at the risk of proving myself an unsuccessful pedant: in a predicate context
(where the answer to the question is true or false), we start w/ the axiom
that the empty list has value nil.  e.g.: (make-list 0 FOO) => nil.  then we
follow this chain of reasoning: non-empty list => non-nil => non-false =>
"close enough to true to be interpreted as true (i.e., far enough from false
to be not interpreted as false)".

the predicate context clamps values.  this clamping is what (seemingly
ironically, one reflects) frees us from strict adherence to "abstraction
purity"; we can move from good design to better design.  [insert spiel about
recognizing premature optimization and shrugging one's shoulders, here...]

to sum up, to answer the question in this particular predicate context, one
need not compute a truth value using a function; it is sufficient to look at
the underlying data structure, i.e., the list as a value held in a variable.

thi

RE: newsticker-start: Recursive laod error

[Drew Adams]

    this is ttn-post-C2H5OH notation :-)

What? Banal C2H5OH? You Thi? I thought your reveries were mused on green tea
and absinthe. Recursive "laod" indeed...

Re: newsticker-start: Recursive laod error

[Ulf Jasper]

OK.  I cut out the '-p' thing. The recursive load error should be fixed
now. Here's the patch

Prost!

ulf

*** newsticker.el	15 Dez 2005 19:34:02 +0100	1.8
--- newsticker.el	15 Dez 2005 20:53:51 +0100	
***************
*** 9,15 ****
  ;; URL:         http://www.nongnu.org/newsticker
  ;; Created:     17. June 2003
  ;; Keywords:    News, RSS, Atom
! ;; Time-stamp:  "1. November 2005, 21:16:53 (ulf)"
  
  ;; ======================================================================
  
--- 9,15 ----
  ;; URL:         http://www.nongnu.org/newsticker
  ;; Created:     17. June 2003
  ;; Keywords:    News, RSS, Atom
! ;; Time-stamp:  "15. Dezember 2005, 20:53:51 (ulf)"
  
  ;; ======================================================================
  
***************
*** 27,33 ****
  ;; along with this program; if not, write to the Free Software Foundation,
  ;; Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
  
! (defconst newsticker-version "1.9" "Version number of newsticker.el.")
  
  ;; ======================================================================
  ;;; Commentary:
--- 27,33 ----
  ;; along with this program; if not, write to the Free Software Foundation,
  ;; Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
  
! (defconst newsticker-version "1.91" "Version number of newsticker.el.")
  
  ;; ======================================================================
  ;;; Commentary:
***************
*** 169,174 ****
--- 169,181 ----
  ;; ======================================================================
  ;;; History:
  
+ ;; 1.91 (2005-12-15)
+ ;;     * Renamed `newsticker--retrieval-timer-list' to
+ ;;       `newsticker-retrieval-timer-list'.  Removed
+ ;;       `newsticker-running-p' -- check newsticker-retrieval-timer-list
+ ;;       to find out whether newsticker is running.  Removed
+ ;;       `newsticker-ticker-running-p'.
+ 
  ;; 1.9 (2005-11-01)
  ;;     * Rewrote feed parsing part.  Newsticker now supports RSS 0.91,
  ;;       0.92, 1.0, 2.0 as well as Atom 0.3 and 1.0 -- thanks to Thien-Thi
***************
*** 453,458 ****
--- 460,470 ----
        (setq element (cdr element)))
      result))
  
+ ;;;###autoload
+ (defvar newsticker-retrieval-timer-list nil
+   "List of timers for news retrieval.
+ This is an alist, each element consisting of (feed-name . timer)")
+ 
  ;; ======================================================================
  ;;; Customization
  ;; ======================================================================
***************
*** 475,488 ****
            ((memq symbol '(newsticker-url-list-defaults
                            newsticker-url-list
                            newsticker-retrieval-interval))
!            (when (and (fboundp 'newsticker-running-p)
!                       (newsticker-running-p))
               (message "Restarting newsticker")
               (newsticker-stop)
               (newsticker-start)))
            ((eq symbol 'newsticker-display-interval)
!            (when (and (fboundp 'newsticker-running-p)
!                       (newsticker-running-p))
               (message "Restarting ticker")
               (newsticker-stop-ticker)
               (newsticker-start-ticker)
--- 487,498 ----
            ((memq symbol '(newsticker-url-list-defaults
                            newsticker-url-list
                            newsticker-retrieval-interval))
!            (when newsticker-retrieval-timer-list
               (message "Restarting newsticker")
               (newsticker-stop)
               (newsticker-start)))
            ((eq symbol 'newsticker-display-interval)
!            (when newsticker-retrieval-timer-list
               (message "Restarting ticker")
               (newsticker-stop-ticker)
               (newsticker-start-ticker)
***************
*** 490,497 ****
            ((memq symbol '(newsticker-hide-old-items-in-echo-area
                            newsticker-hide-obsolete-items-in-echo-area
                            newsticker-hide-immortal-items-in-echo-area))
!            (when (and (fboundp 'newsticker-running-p)
!                       (newsticker-running-p))
               (message "Restarting newsticker")
               (newsticker-stop-ticker)
               (newsticker--ticker-text-setup)
--- 500,506 ----
            ((memq symbol '(newsticker-hide-old-items-in-echo-area
                            newsticker-hide-obsolete-items-in-echo-area
                            newsticker-hide-immortal-items-in-echo-area))
!            (when newsticker-retrieval-timer-list
               (message "Restarting newsticker")
               (newsticker-stop-ticker)
               (newsticker--ticker-text-setup)
***************
*** 1190,1198 ****
  ;; ======================================================================
  (defvar newsticker--display-timer nil
    "Timer for newsticker display.")
- (defvar newsticker--retrieval-timer-list nil
-   "List of timers for news retrieval.
- This is an alist, each element consisting of (feed-name . timer)")
  (defvar newsticker--item-list nil
    "List of newsticker items.")
  (defvar newsticker--item-position 0
--- 1199,1204 ----
***************
*** 2372,2378 ****
  DO-NOT-COMPLAIN-IF-RUNNING is not nil.
  Run `newsticker-start-hook' if newsticker was not running already."
    (interactive)
!   (let ((running (newsticker-running-p)))
      ;; read old cache if it exists and newsticker is not running
      (unless running
        (let* ((coding-system-for-read 'utf-8)
--- 2378,2384 ----
  DO-NOT-COMPLAIN-IF-RUNNING is not nil.
  Run `newsticker-start-hook' if newsticker was not running already."
    (interactive)
!   (let ((running newsticker-retrieval-interval))
      ;; read old cache if it exists and newsticker is not running
      (unless running
        (let* ((coding-system-for-read 'utf-8)
***************
*** 2393,2399 ****
                     (interval (or (nth 3 item)
                                   newsticker-retrieval-interval))
                     (timer (assoc (car item)
!                                  newsticker--retrieval-timer-list)))
                (if timer
                    (or do-not-complain-if-running
                        (message "Timer for %s is running already!"
--- 2399,2405 ----
                     (interval (or (nth 3 item)
                                   newsticker-retrieval-interval))
                     (timer (assoc (car item)
!                                  newsticker-retrieval-timer-list)))
                (if timer
                    (or do-not-complain-if-running
                        (message "Timer for %s is running already!"
***************
*** 2411,2417 ****
                  (setq timer (run-at-time start-time interval
                                           'newsticker-get-news feed-name))
                  (if interval
!                     (add-to-list 'newsticker--retrieval-timer-list
                                   (cons feed-name timer))))))
            (append newsticker-url-list-defaults newsticker-url-list))
      (unless running
--- 2417,2423 ----
                  (setq timer (run-at-time start-time interval
                                           'newsticker-get-news feed-name))
                  (if interval
!                     (add-to-list 'newsticker-retrieval-timer-list
                                   (cons feed-name timer))))))
            (append newsticker-url-list-defaults newsticker-url-list))
      (unless running
***************
*** 2438,2448 ****
    (interactive)
    (newsticker--cache-update t)
    (newsticker-stop-ticker)
!   (when (newsticker-running-p)
      (mapc (lambda (name-and-timer)
              (cancel-timer (cdr name-and-timer)))
!           newsticker--retrieval-timer-list)
!     (setq newsticker--retrieval-timer-list nil)
      (run-hooks 'newsticker-stop-hook)
      (message "Newsticker stopped!")))
  
--- 2444,2454 ----
    (interactive)
    (newsticker--cache-update t)
    (newsticker-stop-ticker)
!   (when newsticker-retrieval-timer-list
      (mapc (lambda (name-and-timer)
              (cancel-timer (cdr name-and-timer)))
!           newsticker-retrieval-timer-list)
!     (setq newsticker-retrieval-timer-list nil)
      (run-hooks 'newsticker-stop-hook)
      (message "Newsticker stopped!")))
  
***************
*** 3079,3102 ****
            (and (memq  age '(new old obsolete)) t)))))
  
  ;; ======================================================================
- ;;; Newsticker status
- ;; ======================================================================
- ;;;###autoload
- (defun newsticker-running-p ()
-   "Check whether newsticker is running.
- Return t if newsticker is running, nil otherwise.  Newsticker is
- considered to be running if the newsticker timer list is not empty."
-   (> (length newsticker--retrieval-timer-list) 0))
- 
- ;;;###autoload
- (defun newsticker-ticker-running-p ()
-   "Check whether newsticker's actual ticker is running.
- Return t if ticker is running, nil otherwise.  Newsticker is
- considered to be running if the newsticker timer list is not
- empty."
-   (timerp newsticker--display-timer))
- 
- ;; ======================================================================
  ;;; local stuff
  ;; ======================================================================
  (defun newsticker-get-news (feed-name)
--- 3085,3090 ----

Documentation for car and cdr

[Mario Domenech Goulart]

Hello,

Currently, the documentation for cdr is:

,----[ M-x describe-function <RET> cdr <RET> ]
| cdr is a built-in function in `C source code'.
| (cdr list)
| 
| Return the cdr of list.  If arg is nil, return nil.
| Error if arg is not nil and not a cons cell.  See also `cdr-safe'.
`----

And, for car, is:

,----[ M-x describe-function <RET> car <RET> ]
| car is a built-in function in `C source code'.
| (car list)
| 
| Return the car of list.  If arg is nil, return nil.
| Error if arg is not nil and not a cons cell.  See also `car-safe'.
`----

Saying "car returns the car" and "cdr returns the cdr" doesn't sound
very useful for me if I would like to know what car and cdr do, unless I
knew what "car" and "cdr" mean (then I wouldn't check the
documentation). :-)

Wouldn't it be better to write something like "Return the first element
of list" and "Return a list containing all but the first element of
list" for car and cdr, respectively?

I found this little "issue" when I was trying to show a friend of mine
the self-documenting features of Emacs: "If you don't know what car
means, for example, you can always check the documentation, so you can
find out that car...  returns the car of a list...". :-) Maybe he
thought lists can drive. :-)


Best wishes,
Mario

Re: Documentation for car and cdr

[Kevin Rodgers]

Mario Domenech Goulart wrote:
> Saying "car returns the car" and "cdr returns the cdr" doesn't sound
> very useful for me if I would like to know what car and cdr do, unless I
> knew what "car" and "cdr" mean (then I wouldn't check the
> documentation). :-)
> 
> Wouldn't it be better to write something like "Return the first element
> of list" and "Return a list containing all but the first element of
> list" for car and cdr, respectively?

I don't think so, but I know Lisp.

> I found this little "issue" when I was trying to show a friend of mine
> the self-documenting features of Emacs: "If you don't know what car
> means, for example, you can always check the documentation, so you can
> find out that car...  returns the car of a list...". :-) Maybe he
> thought lists can drive. :-)

I think it would be useful if the doc string contained a reference
to the "Cons Cells" node of the Emacs Lisp manual.

-- 
Kevin Rodgers

Re: Documentation for car and cdr

[Mario Domenech Goulart]

On Tue, 24 Jan 2006 15:30:21 -0700 Kevin Rodgers <ihs_4664@yahoo.com> wrote:

> Mario Domenech Goulart wrote:
>> Saying "car returns the car" and "cdr returns the cdr" doesn't sound
>> very useful for me if I would like to know what car and cdr do,
>> unless I knew what "car" and "cdr" mean (then I wouldn't check the
>> documentation). :-) Wouldn't it be better to write something like
>> "Return the first element of list" and "Return a list containing all
>> but the first element of list" for car and cdr, respectively?
>
> I don't think so, but I know Lisp.

Since english is not my native language, maybe I'm misunderstanding, but
I noticed a little irony in this sentence (if I'm wrong, I apologize in
advance). 

What I wanted to suggest is something simple as mentioned in the
"An Introduction to Programming in Emacs Lisp" document.

,----[ http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/car---cdr.html ]
| The CDR of a list is the rest of the list, that is, the cdr function
| returns the part of the list that follows the first item.
`----

Again, I'm not sure if I understand you correctly, but it seems to me
that you think the suggestion is not adequate because it's too
simplistic (maybe wrong) and that's the reason of your sentence.


Best wishes,
Mario

Re: Documentation for car and cdr

[David Kastrup]

Mario Domenech Goulart <mario.goulart@gmail.com> writes:

> Hello,
>
> Currently, the documentation for cdr is:
>
> ,----[ M-x describe-function <RET> cdr <RET> ]
> | cdr is a built-in function in `C source code'.
> | (cdr list)
> | 
> | Return the cdr of list.  If arg is nil, return nil.
> | Error if arg is not nil and not a cons cell.  See also `cdr-safe'.
> `----
>
> And, for car, is:
>
> ,----[ M-x describe-function <RET> car <RET> ]
> | car is a built-in function in `C source code'.
> | (car list)
> | 
> | Return the car of list.  If arg is nil, return nil.
> | Error if arg is not nil and not a cons cell.  See also `car-safe'.
> `----
>
> Saying "car returns the car" and "cdr returns the cdr" doesn't sound
> very useful for me if I would like to know what car and cdr do, unless I
> knew what "car" and "cdr" mean (then I wouldn't check the
> documentation). :-)
>
> Wouldn't it be better to write something like "Return the first
> element of list" and "Return a list containing all but the first
> element of list" for car and cdr, respectively?

No.  cons cells don't need to point to an atom in their car, or to a
cons cell or nil in their cdr.  This is fundamental Lisp terminology.
It would be ok to add a cross reference to the Elisp manual, but the
description of the functions is dead-on and should not be replaced by
some watered-down half-inaccurate stuff.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Documentation for car and cdr

[Mario Domenech Goulart]

On Wed, 25 Jan 2006 00:14:32 +0100 David Kastrup <dak@gnu.org> wrote:

> Mario Domenech Goulart <mario.goulart@gmail.com> writes:
>
>> Wouldn't it be better to write something like "Return the first
>> element of list" and "Return a list containing all but the first
>> element of list" for car and cdr, respectively?
>
> No.  cons cells don't need to point to an atom in their car, or to a
> cons cell or nil in their cdr.  This is fundamental Lisp terminology.

Actually I didn't make any assumption about what `element' can be.

But admittedly, the text about cdr is faulty, since (listp '(a . b)) is
t, for example.

Thanks for the comments.

Best wishes.
Mario

Re: Documentation for car and cdr

[David Kastrup]

Mario Domenech Goulart <mario.goulart@gmail.com> writes:

> On Wed, 25 Jan 2006 00:14:32 +0100 David Kastrup <dak@gnu.org> wrote:
>
>> Mario Domenech Goulart <mario.goulart@gmail.com> writes:
>>
>>> Wouldn't it be better to write something like "Return the first
>>> element of list" and "Return a list containing all but the first
>>> element of list" for car and cdr, respectively?
>>
>> No.  cons cells don't need to point to an atom in their car, or to a
>> cons cell or nil in their cdr.  This is fundamental Lisp terminology.
>
> Actually I didn't make any assumption about what `element' can be.

But only true lists have elements like those you write about, dotted
lists haven't.

> But admittedly, the text about cdr is faulty, since (listp '(a . b)) is
> t, for example.

I would not call a the first element of a "list" '(a . b).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Documentation for car and cdr

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> But only true lists have elements like those you write about, dotted
> lists haven't.

Which is why they are called dotted pairs.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Documentation for car and cdr

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> But only true lists have elements like those you write about, dotted
>> lists haven't.
>
> Which is why they are called dotted pairs.

(info "(elisp) Cons Cells")

[...]

   If the CDR of a list's last cons cell is some other value, neither
`nil' nor another cons cell, we call the structure a "dotted list",
since its printed representation would use `.'.  There is one other
possibility: some cons cell's CDR could point to one of the previous
cons cells in the list.  We call that structure a "circular list".


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Documentation for car and cdr

[Richard M. Stallman]

    It would be ok to add a cross reference to the Elisp manual, but the
    description of the functions is dead-on and should not be replaced by
    some watered-down half-inaccurate stuff.

Damn straight!

Re: Documentation for car and cdr

[Alan Mackenzie]

On Wed, 25 Jan 2006, David Kastrup wrote:

>Mario Domenech Goulart <mario.goulart@gmail.com> writes:

>> Hello,

>> Currently, the documentation for cdr is:

>> ,----[ M-x describe-function <RET> cdr <RET> ]
>> | cdr is a built-in function in `C source code'.
>> | (cdr list)
>> | 
>> | Return the cdr of list.  If arg is nil, return nil.
>> | Error if arg is not nil and not a cons cell.  See also `cdr-safe'.
>> `----

[ snip the same for car. ]

>> Saying "car returns the car" and "cdr returns the cdr" doesn't sound
>> very useful for me if I would like to know what car and cdr do, unless
>> I knew what "car" and "cdr" mean (then I wouldn't check the
>> documentation). :-)

>> Wouldn't it be better to write something like "Return the first
>> element of list" and "Return a list containing all but the first
>> element of list" for car and cdr, respectively?

>No.  cons cells don't need to point to an atom in their car, or to a
>cons cell or nil in their cdr.  This is fundamental Lisp terminology.
>It would be ok to add a cross reference to the Elisp manual, but the
>description of the functions is dead-on and should not be replaced by
>some watered-down half-inaccurate stuff.

This description of the function is near useless.  It is pure sophistry to
distinguish between the abstract concept "cdr", and the function "cdr",
as though they were really two different things.  It's the sort of thing
that gets me fuming with rage when I encounter it in proprietary
documentation.

What does this doc-string say to the novice lisp programmer?  It says
"We're telling you that the function called \"cdr\" actually returns the
abstract \"cdr\" of a lisp object, just in case that isn't obvious."  It
goes on, implicitly by omission, to say "if you really don't know what a
cdr is by this stage, you're so stupid that there's no point in us
bothering to tell you."

How many other functions could we describe in this way.  How about
`bobp', for example?  "bobp returns t if bobp is true, otherwise it
returns nil".

I suggest making this doc-string more helpful by appending the following
to it:

"Loosely speaking, the cdr of LIST is LIST without its first element."

, and the other one:

"Loosely speaking, the car of LIST is its first element.".

Each of these sentences is completely accurate (by virtue of "loosely
speaking"), regardless of whether LIST is a list, a dotted pair, or nil.

>David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Munich, Germany)

Re: Documentation for car and cdr

[Bill Atkins]

On 1/25/06, Alan Mackenzie <acm@muc.de> wrote:
>
>
> On Wed, 25 Jan 2006, David Kastrup wrote:
>
> >Mario Domenech Goulart <mario.goulart@gmail.com> writes:
>
> >> Hello,
>
> >> Currently, the documentation for cdr is:
>
> >> ,----[ M-x describe-function <RET> cdr <RET> ]
> >> | cdr is a built-in function in `C source code'.
> >> | (cdr list)
> >> |
> >> | Return the cdr of list.  If arg is nil, return nil.
> >> | Error if arg is not nil and not a cons cell.  See also `cdr-safe'.
> >> `----
>
> [ snip the same for car. ]
>
> >> Saying "car returns the car" and "cdr returns the cdr" doesn't sound
> >> very useful for me if I would like to know what car and cdr do, unless
> >> I knew what "car" and "cdr" mean (then I wouldn't check the
> >> documentation). :-)
>
> >> Wouldn't it be better to write something like "Return the first
> >> element of list" and "Return a list containing all but the first
> >> element of list" for car and cdr, respectively?
>
> >No.  cons cells don't need to point to an atom in their car, or to a
> >cons cell or nil in their cdr.  This is fundamental Lisp terminology.
> >It would be ok to add a cross reference to the Elisp manual, but the
> >description of the functions is dead-on and should not be replaced by
> >some watered-down half-inaccurate stuff.
>
> This description of the function is near useless.  It is pure sophistry to
> distinguish between the abstract concept "cdr", and the function "cdr",
> as though they were really two different things.  It's the sort of thing
> that gets me fuming with rage when I encounter it in proprietary
> documentation.
>
> What does this doc-string say to the novice lisp programmer?  It says
> "We're telling you that the function called \"cdr\" actually returns the
> abstract \"cdr\" of a lisp object, just in case that isn't obvious."  It
> goes on, implicitly by omission, to say "if you really don't know what a
> cdr is by this stage, you're so stupid that there's no point in us
> bothering to tell you."
>
> How many other functions could we describe in this way.  How about
> `bobp', for example?  "bobp returns t if bobp is true, otherwise it
> returns nil".
>
> I suggest making this doc-string more helpful by appending the following
> to it:
>
> "Loosely speaking, the cdr of LIST is LIST without its first element."
>
> , and the other one:
>
> "Loosely speaking, the car of LIST is its first element.".
>
> Each of these sentences is completely accurate (by virtue of "loosely
> speaking"), regardless of whether LIST is a list, a dotted pair, or nil.
>
> >David Kastrup, Kriemhildstr. 15, 44793 Bochum
>
> --
> Alan Mackenzie (Munich, Germany)
>
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

Why do we need to "speak loosely"?  Including a link to a description
of cons cells is completely adequate.

Your definitions are misleading in any case.  CAR and CDR do not
necessarily deal with lists; as others have pointed out, a cons is a
distinct data structure that is used to compose lists only by
convention.  These are not "abstract concepts," they're simply how
Lisp works.

--
Bill Atkins

Re: Documentation for car and cdr

[Alan Mackenzie]

On Wed, 25 Jan 2006, Bill Atkins wrote:

>On 1/25/06, Alan Mackenzie <acm@muc.de> wrote:


>> On Wed, 25 Jan 2006, David Kastrup wrote:

>> >Mario Domenech Goulart <mario.goulart@gmail.com> writes:

>> >> Hello,

>> >> Currently, the documentation for cdr is:

>> >> ,----[ M-x describe-function <RET> cdr <RET> ]
>> >> | cdr is a built-in function in `C source code'.
>> >> | (cdr list)
>> >> |
>> >> | Return the cdr of list.  If arg is nil, return nil.
>> >> | Error if arg is not nil and not a cons cell.  See also `cdr-safe'.
>> >> `----

>> [ snip the same for car. ]

>> >> Saying "car returns the car" and "cdr returns the cdr" doesn't sound
>> >> very useful for me if I would like to know what car and cdr do, unless
>> >> I knew what "car" and "cdr" mean (then I wouldn't check the
>> >> documentation). :-)

>> >> Wouldn't it be better to write something like "Return the first
>> >> element of list" and "Return a list containing all but the first
>> >> element of list" for car and cdr, respectively?

>> >No.  cons cells don't need to point to an atom in their car, or to a
>> >cons cell or nil in their cdr.  This is fundamental Lisp terminology.
>> >It would be ok to add a cross reference to the Elisp manual, but the
>> >description of the functions is dead-on and should not be replaced by
>> >some watered-down half-inaccurate stuff.

>> This description of the function is near useless.  It is pure sophistry to
>> distinguish between the abstract concept "cdr", and the function "cdr",
>> as though they were really two different things.  It's the sort of thing
>> that gets me fuming with rage when I encounter it in proprietary
>> documentation.

>> What does this doc-string say to the novice lisp programmer?  It says
>> "We're telling you that the function called \"cdr\" actually returns the
>> abstract \"cdr\" of a lisp object, just in case that isn't obvious."  It
>> goes on, implicitly by omission, to say "if you really don't know what a
>> cdr is by this stage, you're so stupid that there's no point in us
>> bothering to tell you."

>> How many other functions could we describe in this way.  How about
>> `bobp', for example?  "bobp returns t if bobp is true, otherwise it
>> returns nil".

>> I suggest making this doc-string more helpful by appending the following
>> to it:

>> "Loosely speaking, the cdr of LIST is LIST without its first element."

>> , and the other one:

>> "Loosely speaking, the car of LIST is its first element.".

>> Each of these sentences is completely accurate (by virtue of "loosely
>> speaking"), regardless of whether LIST is a list, a dotted pair, or nil.

>> >David Kastrup, Kriemhildstr. 15, 44793 Bochum

>> --
>> Alan Mackenzie (Munich, Germany)


>Why do we need to "speak loosely"?

So as to be immediately understandable.

>Including a link to a description of cons cells is completely adequate.

Yes, but only in addition to an intuitively meaningful description, not
instead of it.  Because that would force the poor hacker to go and look
somewhere else.  Having to go and look somewhere else is always a pain in
the posterior, particularly when a one-liner explanation is all that is
sought.

>Your definitions are misleading in any case.  CAR and CDR do not
>necessarily deal with lists;

It is merely that the parameter to cdr is called LIST.  I haven't
otherwise implied that it must be a list.  For example "(a . b)" without
it's first element is "b", or something like it.

>as others have pointed out, a cons is a distinct data structure that is
>used to compose lists only by convention.  These are not "abstract
>concepts," they're simply how Lisp works.

We're reduced to silly semantic arguments about "abstract" now.  Others
have asserted that "cdr returns the cdr" is a coherent description of
cdr.  They are thus implying that "cdr" is semantically different from
"cdr", otherwise that description would be circular and vacuous.  I
disagree with them, and used the term "abstract concept" only to try to
highlight what to me is an absurdity.

>--
>Bill Atkins

-- 
Alan Mackenzie (Munich, Germany)

Re: Documentation for car and cdr

[Bill Atkins]

On 1/25/06, Alan Mackenzie <acm@muc.de> wrote:

> >Why do we need to "speak loosely"?
>
> So as to be immediately understandable.
>
> >Including a link to a description of cons cells is completely adequate.
>
> Yes, but only in addition to an intuitively meaningful description, not
> instead of it.  Because that would force the poor hacker to go and look
> somewhere else.  Having to go and look somewhere else is always a pain in
> the posterior, particularly when a one-liner explanation is all that is
> sought.

If you're writing Elisp code, and you need to go to the documentation
for CAR and CDR, you're probably better off reading an introduction to
Lisp (or following a link to an explanation of cons cells).

> >Your definitions are misleading in any case.  CAR and CDR do not
> >necessarily deal with lists;
>
> It is merely that the parameter to cdr is called LIST.  I haven't
> otherwise implied that it must be a list.  For example "(a . b)" without
> it's first element is "b", or something like it.
>
> >as others have pointed out, a cons is a distinct data structure that is
> >used to compose lists only by convention.  These are not "abstract
> >concepts," they're simply how Lisp works.
>
> We're reduced to silly semantic arguments about "abstract" now.  Others
> have asserted that "cdr returns the cdr" is a coherent description of
> cdr.  They are thus implying that "cdr" is semantically different from
> "cdr", otherwise that description would be circular and vacuous.  I
> disagree with them, and used the term "abstract concept" only to try to
> highlight what to me is an absurdity.

A car is the first element of a cons; a cdr is the second.  That's
pretty concrete.

> >--
> >Bill Atkins
>
> --
> Alan Mackenzie (Munich, Germany)
>
>
>


--
Bill Atkins

Re: Documentation for car and cdr

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Wed, 25 Jan 2006, Bill Atkins wrote:
>
>>Why do we need to "speak loosely"?
>
> So as to be immediately understandable.

But the understanding will be faulty.  There is no way we can be
immediately understandable if the concept of a cons cell is unknown.

>>Including a link to a description of cons cells is completely
>>adequate.
>
> Yes, but only in addition to an intuitively meaningful description,
> not instead of it.

Intuitively meaningful is no substitute for correct.

> Because that would force the poor hacker to go and look somewhere
> else.

We don't explain the concept of addition in the doc string for +, or
the concept of comparisons in the doc string for >.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Documentation for car and cdr

[Thien-Thi Nguyen]

Alan Mackenzie <acm@muc.de> writes:

> Because that would force the poor hacker to go and look
> somewhere else.  Having to go and look somewhere else is always
> a pain in the posterior, particularly when a one-liner
> explanation is all that is sought.

if a "hacker" feels "forced" to search widely due to not
understanding something, then that is a poor hacker indeed!

a righteous hacker (fledgling or otherwise) would happily snort
the challenging docstring like the gateway drug it is, disappear
for a few days imbibing more in-depth documentation, and reappear
later wielding `M-x report-emacs-bug' on those bits, instead (if
need be).

we can drop (or ignore) the hacker mystique if we want, but it's
easier to tell ordinary programmers: try to emulate the hackers.
luckily in this case, that is the best advice to give.  climb the
trunk feet skyward; dance on the leaves but hold on to the root.

thi

Re: Documentation for car and cdr

[Lennart Borgman]

Thien-Thi Nguyen wrote:
> a righteous hacker (fledgling or otherwise) would happily snort
> the challenging docstring like the gateway drug it is, disappear
> for a few days imbibing more in-depth documentation, and reappear
> later wielding `M-x report-emacs-bug' on those bits, instead (if
> need be).
>   
And maybe search the Internet for what "car" is.

Re: Documentation for car and cdr

[Thien-Thi Nguyen]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> And maybe search the Internet for what "car" is.

  the car of life, a moment's thought.
  held but briefly, once popped is naught.
  worry instead about the cdr:
  docs still unread, shiver and shudder.
  will i know what to do when i arrive?
  will ending be nil, or a circle alive?

  seeding the search engines, contextually void?
  are people so stateless, never alloyed?
  ADHD flutter-bys, typists ungrounded,
  banging 150wpm, yet self-simply confounded.
  will they know what to grok when they see?
  will internalized concepts be spaghetti or tree?

  thi

Documentation is like term insurance: It satisfies because
almost no one who subscribes to it depends on its benefits.
                                -- Alan Perlis

RE: Documentation for car and cdr

[Drew Adams]

      the car of life, a moment's thought.
      held but briefly, once popped is naught.
      worry instead about the cdr:
      docs still unread, shiver and shudder.
      will i know what to do when i arrive?
      will ending be nil, or a circle alive?
    
An Innational Anthem cons-summated.

And the Flag shall be Boolean )gray0 on gray100?(.

RE: Documentation for car and cdr

[Drew Adams]

    a righteous hacker (fledgling or otherwise) would happily snort
    the challenging docstring like the gateway drug it is, disappear
    for a few days imbibing more in-depth documentation, and reappear
    later wielding `M-x report-emacs-bug' on those bits, instead (if
    need be).

With respect - http://www.emacswiki.org/cgi-bin/wiki/EmacsKoans#DocString.

Re: Documentation for car and cdr

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> Others have asserted that "cdr returns the cdr" is a coherent
> description of cdr.  They are thus implying that "cdr" is semantically
> different from "cdr", otherwise that description would be circular and
> vacuous.

Er, well they _are_ different in that sentence -- the first "cdr" is a
function, the second "cdr" is the name of part of a data-structure.

I guess this thread has become a bit overblown (this is a minor issue!),
but I agree that in some cases it might nice to describe the "list
meaning" of such functions as an addendum, to help beginners.

E.g.

   Return the cdr of the cons-cell CONS.  If CONS is nil, return nil.
   Signal an error if CONS is not nil and not a cons cell.
   See also `cdr-safe'.

   When CONS is interpreted as a list, cdr returns the list tail
   (the list with the first member removed).

-miles
-- 
Run away!  Run away!

Re: Documentation for car and cdr

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> Others have asserted that "cdr returns the cdr" is a coherent
> description of cdr.  They are thus implying that "cdr" is semantically
> different from "cdr", otherwise that description would be circular and
> vacuous.

Er, well they _are_ different in that sentence -- the first "cdr" is a
function, the second "cdr" is the name of part of a data-structure.

I guess this thread has become a bit overblown (this is a minor issue!),
but I agree that in some cases it might nice to describe the "list
meaning" of such functions as an addendum, to help beginners.

E.g.

   Return the cdr of the cons-cell CONS.  If CONS is nil, return nil.
   Signal an error if CONS is not nil and not a cons cell.
   See also `cdr-safe'.

   When CONS is interpreted as a list, cdr returns the list tail
   (the list with the first member removed).

-miles
-- 
Run away!  Run away!

Re: Documentation for car and cdr

[Lennart Borgman]

Alan Mackenzie wrote:
> What does this doc-string say to the novice lisp programmer?  It says
> "We're telling you that the function called \"cdr\" actually returns the
> abstract \"cdr\" of a lisp object, just in case that isn't obvious."  It
> goes on, implicitly by omission, to say "if you really don't know what a
> cdr is by this stage, you're so stupid that there's no point in us
> bothering to tell you."
> ...
> I suggest making this doc-string more helpful by appending the following
> to it:
>
> "Loosely speaking, the cdr of LIST is LIST without its first element."
>   
This is a very good idea since the beginner might remember that one of 
the gives the first (or was it last?) element and the other gives the rest.

Giving a link to the info node is of course also very good.

Re: Documentation for car and cdr

[Alfred M. Szmidt]

   >> ,----[ M-x describe-function <RET> cdr <RET> ]
   >> | cdr is a built-in function in `C source code'.
   >> | (cdr list)
   >> | 
   >> | Return the cdr of list.  If arg is nil, return nil.
   >> | Error if arg is not nil and not a cons cell.  See also `cdr-safe'.
   >> `----

[...]

   This description of the function is near useless.

The same applies to many other functions, take bobp and a novice
programmer, and she will ask `what is a buffer?'.  Some level of
knowledge about the function must be assumed for docstrings.  What the
car/cdr of a list is, is already explained in the Introduction to
Emacs Lisp manual and that is where a novice programmer will have to
start to understand many things about emacs, like lists, frames,
windows, buffers, arrays, strings, vectors, special forms, etc.

Re: Documentation for car and cdr

[Thien-Thi Nguyen]

Alan Mackenzie <acm@muc.de> writes:

> Each of these sentences is completely accurate (by virtue of "loosely
> speaking"), regardless of whether LIST is a list, a dotted pair, or
> nil.

blech.  placing "loosely speaking" in the docstring decreases
credibility (take it from a practiced word weasler: those are weasel
words), and does not clarify anything.  that's certainly a bad move.

(note: CERTAINLY, not just LOOSELY SPEAKING.)

this whole thread is populated by people who know what CAR and CDR are.
people who don't, who *might* be confused, who *may* be offended by such
crass self-documentation; they won't read this or the docstring anyway!

now, i suppose someone will lark an ostensibly non-expert friend into
sending a bug report on this.  what, is it 1-april already?

thi

Re: Documentation for car and cdr

[Alan Mackenzie]

Hi, Thi!

On 25 Jan 2006, Thien-Thi Nguyen wrote:

>Alan Mackenzie <acm@muc.de> writes:

>> Each of these sentences is completely accurate (by virtue of "loosely
>> speaking"), regardless of whether LIST is a list, a dotted pair, or
>> nil.

>blech.  placing "loosely speaking" in the docstring decreases
>credibility (take it from a practiced word weasler: those are weasel
>words), and does not clarify anything.  that's certainly a bad move.

How would you answer "What's Emacs?".  "Loosely speaking, it's a
programmers' editor" is correct, and a good answer.  "A programmers'
editor" will raise the hackles of Gnus fans and some professional
writers.  "An extensible editing system, programmed in lisp, including
specialized facilities for ..... [ snip next 10 line ]" will bore the
questioner to tears and make him wish he hadn't asked.  "It's Emacs!" is
vacuous.

Describing intuitively what car/cdr mean is useful.  I think that "car
returns the car" and "cdr returns the cdr" have negative value - they
irritate without enlightening.

>(note: CERTAINLY, not just LOOSELY SPEAKING.)

>this whole thread is populated by people who know what CAR and CDR are.
>people who don't, who *might* be confused, who *may* be offended by such
>crass self-documentation; they won't read this or the docstring anyway!

Again, I disagree.  A fledgling Elisp hacker is likely to spend time
reading through existing code.  She's likely to expect C-h f to tell her
what the mysterious functions do.

>now, i suppose someone will lark an ostensibly non-expert friend into
>sending a bug report on this.  what, is it 1-april already?

I submitted precisely this issue as a bug a little over a year ago.  (And
no, I have not communicated with the OP in this thread.)  From that
discussion, and this one, it seems clear that people have widely varying
expectations of what doc-strings should be.  David K. wants rigour at all
costs;  The OP and I want clarity.  Most doc strings are rigorous, clear
and helpful at the same time.  Why can't those for car and cdr also be
so?

>thi

-- 
Alan.

Re: Documentation for car and cdr

[Karl Chen]

I agree with Alan Mackenzie's position that the docstring needs to
explain.

Yes, "car returns the first element of a list" is wrong.  But that
doesn't mean we can't add something good, helpful in addition to
the precise statement that experienced lisp hackers want ("the car
function returns the car").

The information could be in the manual.  Is there anything
currently?  I couldn't find any nodes on "cons cells" or "cdr".

The Wikipedia (licensed under GFDL) entry for "Car and cdr" is
reasonably introductory and seems accurate as far as explaining
the special case of using of car/cdr in lists as first/butfirst.

http://en.wikipedia.org/wiki/Car_and_cdr


-- 
Karl 2006-01-25 15:58

Re: Documentation for car and cdr

[Luc Teirlinck]

Karl Chen wrote:

   The information could be in the manual.  Is there anything
   currently?  I couldn't find any nodes on "cons cells"

`C-h i g (elisp)Cons Cells'

   or "cdr".

`C-h i g (elisp)List Elements'

Sincerely,

Luc.

Re: Documentation for car and cdr

[Eli Zaretskii]

> Date: Wed, 25 Jan 2006 18:18:19 -0600 (CST)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> Cc: emacs-devel@gnu.org
> 
> Karl Chen wrote:
> 
>    The information could be in the manual.  Is there anything
>    currently?  I couldn't find any nodes on "cons cells"
> 
> `C-h i g (elisp)Cons Cells'
> 
>    or "cdr".
> 
> `C-h i g (elisp)List Elements'

Actually, "C-h i i cdr" is simpler (and requires less a-priori
knowledge).

Re: Documentation for car and cdr

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Actually, "C-h i i cdr" is simpler (and requires less a-priori
> knowledge).

It only works if you happened to already be visiting the elisp manual
though...

-miles
-- 
"Suppose He doesn't give a shit?  Suppose there is a God but He
just doesn't give a shit?"  [George Carlin]

Re: Documentation for car and cdr

[Thien-Thi Nguyen]

Alan Mackenzie <acm@muc.de> writes:

> I think that "car returns the car" and "cdr returns the cdr" have
> negative value - they irritate without enlightening.

the irritation is not inherent in the text of a docstring, and neither
is the process of enlightenment (if any).

> Again, I disagree.  A fledgling Elisp hacker is likely to spend time
> reading through existing code.  She's likely to expect C-h f to tell her
> what the mysterious functions do.

how the fledgling hacker handles unfulfilled expectations is probably a
nice thing for the fledgling hacker to hack, rather than the docstring.

> The OP and I want clarity.  Most doc strings are rigorous, clear and
> helpful at the same time.  Why can't those for car and cdr also be so?
 
it can't be so when someone doesn't let it be so.

thi

Re: Documentation for car and cdr

[Alan Mackenzie]

Hi, Thi!

On 25 Jan 2006, Thien-Thi Nguyen wrote:

>Alan Mackenzie <acm@muc.de> writes:

>> I think that "car returns the car" and "cdr returns the cdr" have
>> negative value - they irritate without enlightening.

>the irritation is not inherent in the text of a docstring, and neither
>is the process of enlightenment (if any).

I didn't suggest they were.  Merely that these doc-strings irritate, and
that they fail to enlighten.  If they didn't irritate, would so many
people have contributed to this thread?  ;-)

>> Again, I disagree.  A fledgling Elisp hacker is likely to spend time
>> reading through existing code.  She's likely to expect C-h f to tell
>> her what the mysterious functions do.

>how the fledgling hacker handles unfulfilled expectations is probably a
>nice thing for the fledgling hacker to hack, rather than the docstring.

>> The OP and I want clarity.  Most doc strings are rigorous, clear and
>> helpful at the same time.  Why can't those for car and cdr also be so?
 
>it can't be so when someone doesn't let it be so.

OK, here are my suggestions.  I think they they are both clear enough and
rigorous enough:

" car is a built-in function.
  (car CONS)

  Return the car of CONS.  If CONS is nil, return nil.
  The car of a list or a dotted pair is its first element.

  Error if CONS is not nil and not a cons cell.  See also `car-safe'."

and

" cdr is a built-in function.
  (cdr CONS)

  Return the cdr of CONS.  If CONS is nil, return nil.
  The cdr of a list is the list without its first element.  The cdr of a
  dotted pair (A . B) is the second element, B.

  Error if arg is not nil and not a cons cell.  See also `cdr-safe'."


>thi

-- 
Alan.

Re: Documentation for car and cdr

[Tomas Zerolo]

[-- Attachment #1.1: Type: text/plain, Size: 569 bytes --]

On Thu, Jan 26, 2006 at 09:34:43AM +0000, Alan Mackenzie wrote:
[...]
> OK, here are my suggestions.  I think they they are both clear enough and
> rigorous enough:
> 
> " car is a built-in function.
>   (car CONS)
> 
>   Return the car of CONS.  If CONS is nil, return nil.
>   The car of a list or a dotted pair is its first element.
> 
>   Error if CONS is not nil and not a cons cell.  See also `car-safe'."

[similar CDR suggestion snipped]

I actually liked your first suggestions better. I know it is
controversial here :-)

Regards
-- tomas

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Documentation for car and cdr

[Thien-Thi Nguyen]

Alan Mackenzie <acm@muc.de> writes:

> If they didn't irritate, would so many
> people have contributed to this thread?  ;-)

well, some of us procrastinate narcistically.

thi

Re: Documentation for car and cdr

[Luc Teirlinck]

Describing basic concepts like car, cdr, cons cell, list and so on is
the task of manuals, not of docstrings.  If somebody is not familiar
with the basic concepts, they have to read a manual, where those
concepts can be put into the proper context, _not_ individual docstrings.

There are two different Elisp manuals included with the Emacs
distribution.  Why on earth would a beginning Elisp programmer try to
learn Elisp exclusively through the docstrings rather than through the
one of these two manuals?

Sincerely,

Luc.

Re: Documentation for car and cdr

[Alan Mackenzie]

On Wed, 25 Jan 2006, Luc Teirlinck wrote:

>Describing basic concepts like car, cdr, cons cell, list and so on is
>the task of manuals, not of docstrings.

That has not been established.  And even if it had, a one-liner
description in a doc-string is likely to be convenient and helpful.

>If somebody is not familiar with the basic concepts, they have to read a
>manual, where those concepts can be put into the proper context, _not_
>individual docstrings.

Suppose somebody has read the manuals, a bit.  She knows what car and cdr
mean, roughly, but isn't quite sure which is which.  C-h f is a
convenient way of checking.  Or it could be.

>There are two different Elisp manuals included with the Emacs
>distribution.  Why on earth would a beginning Elisp programmer try to
>learn Elisp exclusively through the docstrings rather than through the
>one of these two manuals?

Your begging the question here.  I don't think anybody (least of all me)
is suggesting that doc-strings should supplant the manuals.  But I am
saying that somebody needing a short snappy one-liner description of a
function shouldn't be forced to go through the drudgery of opening the
Elisp manual, finding the page "cdr" is on, then ploughing through all
the "broadening your horizons" documentation to reach that one critical
sentence.

Different people use manuals and doc-strings in different ways.

>Sincerely,

>Luc.

-- 
Alan.

Re: Documentation for car and cdr

[Tomas Zerolo]

[-- Attachment #1.1: Type: text/plain, Size: 684 bytes --]

On Wed, Jan 25, 2006 at 10:35:32PM +0000, Alan Mackenzie wrote:

[...]
> That has not been established.  And even if it had, a one-liner
> description in a doc-string is likely to be convenient and helpful.

Sorry for chiming in into an already long thread, but by past experience
(esp. with Emacs docs) I'm with Alan on this one. A small pointer (those
by Alan or Miles seem quite good) which might lead the reader into the
right direction is much better than nothing. Even if they are a bit
blurry. Stating that the pointer *is* indeed an oversimplification and
providing a link into the doc for the ``whole story'' makes up for any
Semantical Incorrectness. Imho.

Thanks
-- tomas

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Documentation for car and cdr

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Describing basic concepts like car, cdr, cons cell, list and so on is
> the task of manuals, not of docstrings.  If somebody is not familiar
> with the basic concepts, they have to read a manual, where those
> concepts can be put into the proper context, _not_ individual docstrings.

I fully agree, but notice that the doc strings for car and cdr 
say that the arg is "list".  I think that part of the confusion
is that a "pure" list does have a head and a tail and car==head
and cdr==tail.

It might better to change the arg from "list" to "cons", i.e.

car is a built-in function in `C source code'.
(car CONS)

Return the car of cons cell CONS.  If arg is nil, return nil.
Error if arg is not nil and not a cons cell.  See also `car-safe'.


cdr is a built-in function in `C source code'.
(cdr CONS)

Return the cdr of cons cell CONS.  If arg is nil, return nil.
Error if arg is not nil and not a cons cell.  See also `cdr-safe'.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Documentation for car and cdr

[Peter Whaite]

Kim F. Storm <storm@cua.dk> wrote:
> 
> I fully agree, but notice that the doc strings for car and cdr 
> say that the arg is "list".  I think that part of the confusion
> is that a "pure" list does have a head and a tail and car==head
> and cdr==tail.

Yes exactly right.  As it is now the  doc string gives the
misleading impression that c[ad]r operate on lists when they don't.


-- 
Peter Whaite

Re: Documentation for car and cdr

[David Kastrup]

Peter Whaite <emacs@whaite.ca> writes:

> Kim F. Storm <storm@cua.dk> wrote:
>> 
>> I fully agree, but notice that the doc strings for car and cdr 
>> say that the arg is "list".  I think that part of the confusion
>> is that a "pure" list does have a head and a tail and car==head
>> and cdr==tail.
>
> Yes exactly right.  As it is now the  doc string gives the
> misleading impression that c[ad]r operate on lists when they don't.

The terminology in the Elisp manual distinguishes between "true
lists", "circular lists" and "dotted lists".  So a cons cell is a list
always, though not necessarily a "true list".  listp returns t
whenever we have a cons cell or nil.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Documentation for car and cdr

[Mario Domenech Goulart]

On Wed, 25 Jan 2006 23:51:38 +0100 storm@cua.dk (Kim F. Storm) wrote:

> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>
>> Describing basic concepts like car, cdr, cons cell, list and so on is
>> the task of manuals, not of docstrings.  If somebody is not familiar
>> with the basic concepts, they have to read a manual, where those
>> concepts can be put into the proper context, _not_ individual docstrings.
>
> I fully agree, but notice that the doc strings for car and cdr 
> say that the arg is "list".  I think that part of the confusion
> is that a "pure" list does have a head and a tail and car==head
> and cdr==tail.

Thanks for focusing this point, Kim.  I think it's certainly part of the
confusion (specially if you are used to Scheme...).


> It might better to change the arg from "list" to "cons"

I agree.


Best wishes,
Mario

Re: Documentation for car and cdr

[Richard M. Stallman]

    Return the car of cons cell CONS.  If arg is nil, return nil.
    Error if arg is not nil and not a cons cell.  See also `car-safe'.

How about this:

    Return the car of cons cell (or list) CONS.  If arg is nil, return nil.
    Error if arg is not nil and not a cons cell.  See also `car-safe'.

Re: Documentation for car and cdr

[Luc Teirlinck]

Richard Stallman wrote:

   How about this:

       Return the car of cons cell (or list) CONS.  If arg is nil, return nil.
       Error if arg is not nil and not a cons cell.  See also `car-safe'.

Violates the convention stated in `(elisp)Documentation Tips' that the
first line of a docstring should not be wider than 67 characters.
(71 in this case.)  The only list that is not a cons cell is nil,
which is mentioned on the same line.

Sincerely,

Luc.

Re: Documentation for car and cdr

[Peter Whaite]

Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> The only list that is not a cons cell is nil.

Actually I seem to remember learning that nil _was_ a cons cell where
both the car and cdr pointed to itself.  That makes it unnecessary to
treat nil as a special case.

But that was a long time ago.

-- 
Peter Whaite

Re: Documentation for car and cdr

[Kevin Rodgers]

Peter Whaite wrote:
> Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
>>The only list that is not a cons cell is nil.
> 
> Actually I seem to remember learning that nil _was_ a cons cell where
> both the car and cdr pointed to itself.  That makes it unnecessary to
> treat nil as a special case.
> 
> But that was a long time ago.

I learned Lisp 20+ years ago, and nil has always been an atom (in fact,
a symbol whose value is itself, just like t and now keywords).  A cons
cell like you describe would be a circular structure:

	+----+   +----+
	|    |   |    |
	|    v   v    |
	|  +---+---+  |
	|  |   |   +--+
	|  +-+-+---+
	|    |
	+----+

(let ((print-circle t)
       (cons-cell (cons nil nil)))
   (setcar cons-cell cons-cell)
   (setcdr cons-cell cons-cell)
   cons-cell) ==>
(#0 . #0)

If the symbol nil had such a value, (eq nil 'nil) would not be true.

-- 
Kevin Rodgers

Re: Documentation for car and cdr

[Jose E. Marchesi]

    
    	+----+   +----+
    	|    |   |    |
    	|    v   v    |
    	|  +---+---+  |
    	|  |   |   +--+
    	|  +-+-+---+
    	|    |
    	+----+
    
    (let ((print-circle t)
           (cons-cell (cons nil nil)))
       (setcar cons-cell cons-cell)
       (setcdr cons-cell cons-cell)
       cons-cell) ==>
    (#0 . #0)
    
    If the symbol nil had such a value, (eq nil 'nil) would not be true.


OLE!!!!!!

;)

-- 
José E. Marchesi  <jemarch@gnu.org>
                  <jemarch@es.gnu.org>

GNUs Not Unix!    http://www.gnu.org
GNU Spain         http://es.gnu.org

Re: Documentation for car and cdr

[Peter Whaite]

Kevin Rodgers <ihs_4664@yahoo.com> wrote:
> I learned Lisp 20+ years ago, and nil has always been an atom (in fact,
> a symbol whose value is itself, just like t and now keywords).

Yes it was that long ago and perhaps that is what I recall.

> A cons cell like you describe would be a circular structure:

There was a diagram like that, and I remember being struck at the time
by the beauty and simplicity of it.  I think I still have the old notes
in a box -- I should take a look and see what it was I really learnt.


-- 
Peter Whaite

Re: Documentation for car and cdr

[Jason Rumney]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Return the car of cons cell CONS.  If arg is nil, return nil.
>     Error if arg is not nil and not a cons cell.  See also `car-safe'.
>
> How about this:
>
>     Return the car of cons cell (or list) CONS.  If arg is nil, return nil.
>     Error if arg is not nil and not a cons cell.  See also `car-safe'.

This might make it a little clearer to a new user that a cons cell is
somehow related to a list. It does not make the meaning of the vehicle
preceding that any clearer to someone unfamiliar with the instruction
set of a Lisp Machine.

Re: Documentation for car and cdr

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Return the car of cons cell CONS.  If arg is nil, return nil.
>     Error if arg is not nil and not a cons cell.  See also `car-safe'.
>
> How about this:
>
>     Return the car of cons cell (or list) CONS.  If arg is nil, return nil.
>     Error if arg is not nil and not a cons cell.  See also `car-safe'.

No, I liked, if at all, Alan's last suggestion better.  Your wording
suggests that a cons cell and a list are different things, but a cons
cell.  And I think "car of a list" strange terminology, anyway.  Lists
have elements, not cars.  I'd talk about "car of a cons" and "first
element of a list".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Documentation for car and cdr

[Richard M. Stallman]

    Describing basic concepts like car, cdr, cons cell, list and so on is
    the task of manuals, not of docstrings.  If somebody is not familiar
    with the basic concepts, they have to read a manual, where those
    concepts can be put into the proper context, _not_ individual docstrings.

Hear, hear!

I suggest we drop this thread.