* jit-lock-stealth-load
[not found] ` <8361-Fri22Mar2002162500+0200-eliz@is.elta.co.il>
@ 2002-03-22 17:19 ` Stephen Gildea
2002-03-24 6:13 ` jit-lock-stealth-load Eli Zaretskii
2002-03-24 15:53 ` jit-lock-stealth-load Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Stephen Gildea @ 2002-03-22 17:19 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: jit-lock-stealth-load
2002-03-22 17:19 ` jit-lock-stealth-load Stephen Gildea
@ 2002-03-24 6:13 ` Eli Zaretskii
2002-03-24 15:53 ` jit-lock-stealth-load Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-03-24 6:13 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: jit-lock-stealth-load
2002-03-22 17:19 ` jit-lock-stealth-load Stephen Gildea
2002-03-24 6:13 ` jit-lock-stealth-load Eli Zaretskii
@ 2002-03-24 15:53 ` Richard Stallman
2002-03-25 2:10 ` jit-lock-stealth-load Stephen Gildea
2002-03-25 9:14 ` jit-lock-stealth-load Francesco Potorti`
1 sibling, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-03-24 15:53 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: jit-lock-stealth-load
2002-03-24 15:53 ` jit-lock-stealth-load Richard Stallman
@ 2002-03-25 2:10 ` Stephen Gildea
2002-03-26 8:50 ` jit-lock-stealth-load Richard Stallman
2002-03-25 9:14 ` jit-lock-stealth-load Francesco Potorti`
1 sibling, 1 reply; 1364+ messages in thread
From: Stephen Gildea @ 2002-03-25 2:10 UTC (permalink / raw
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: jit-lock-stealth-load
2002-03-24 15:53 ` jit-lock-stealth-load Richard Stallman
2002-03-25 2:10 ` jit-lock-stealth-load Stephen Gildea
@ 2002-03-25 9:14 ` Francesco Potorti`
1 sibling, 0 replies; 1364+ messages in thread
From: Francesco Potorti` @ 2002-03-25 9:14 UTC (permalink / raw
Cc: gildea, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: jit-lock-stealth-load
2002-03-25 2:10 ` jit-lock-stealth-load Stephen Gildea
@ 2002-03-26 8:50 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-03-26 8:50 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Bug#139792: emacs21: Press PageDown, get infinite loop
[not found] ` <E16yQmB-0002oh-00@blackbird.home.nickwillson.com>
@ 2002-04-19 18:43 ` Richard Stallman
[not found] ` <rms@gnu.org>
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-04-19 18:43 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Bug#139792: emacs21: Press PageDown, get infinite loop
[not found] ` <rms@gnu.org>
@ 2002-04-20 22:04 ` Nick
2003-01-05 8:12 ` Emacs crash in X Satyaki Das
` (3 subsequent siblings)
4 siblings, 0 replies; 1364+ messages in thread
From: Nick @ 2002-04-20 22:04 UTC (permalink / raw
Cc: emacs-devel
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.
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
[not found] ` <1438-Thu25Apr2002222156+0300-eliz@is.elta.co.il>
@ 2002-04-26 17:38 ` Richard Stallman
2002-04-26 18:26 ` Stephen Gildea
2002-04-26 19:22 ` Eli Zaretskii
0 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-04-26 17:38 UTC (permalink / raw
Cc: gildea, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-26 17:38 ` decode_eol and inconsistent EOL Richard Stallman
@ 2002-04-26 18:26 ` Stephen Gildea
2002-04-26 19:22 ` Eli Zaretskii
1 sibling, 0 replies; 1364+ messages in thread
From: Stephen Gildea @ 2002-04-26 18:26 UTC (permalink / raw
> 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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-26 17:38 ` decode_eol and inconsistent EOL Richard Stallman
2002-04-26 18:26 ` Stephen Gildea
@ 2002-04-26 19:22 ` Eli Zaretskii
2002-04-26 20:39 ` Stefan Monnier
2002-04-28 21:17 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-04-26 19:22 UTC (permalink / raw
Cc: gildea, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-26 19:22 ` Eli Zaretskii
@ 2002-04-26 20:39 ` Stefan Monnier
2002-04-27 8:14 ` Eli Zaretskii
2002-04-28 21:17 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-04-26 20:39 UTC (permalink / raw
Cc: rms, gildea, emacs-devel
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-26 20:39 ` Stefan Monnier
@ 2002-04-27 8:14 ` Eli Zaretskii
2002-04-28 22:40 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-04-27 8:14 UTC (permalink / raw
Cc: rms, gildea, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-26 19:22 ` Eli Zaretskii
2002-04-26 20:39 ` Stefan Monnier
@ 2002-04-28 21:17 ` Richard Stallman
2002-04-29 4:49 ` Eli Zaretskii
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-04-28 21:17 UTC (permalink / raw
Cc: gildea, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-27 8:14 ` Eli Zaretskii
@ 2002-04-28 22:40 ` Stefan Monnier
2002-04-29 4:54 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-04-28 22:40 UTC (permalink / raw
Cc: monnier+gnu/emacs, rms, gildea, emacs-devel
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-28 21:17 ` Richard Stallman
@ 2002-04-29 4:49 ` Eli Zaretskii
2002-04-29 5:37 ` Andrew Choi
2002-04-29 18:40 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-04-29 4:49 UTC (permalink / raw
Cc: gildea, emacs-devel, 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.
But I don't use the Mac, so perhaps such problems don't exist there.
Andrew, could you please advise? Thanks.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-28 22:40 ` Stefan Monnier
@ 2002-04-29 4:54 ` Eli Zaretskii
2002-04-29 13:02 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-04-29 4:54 UTC (permalink / raw
Cc: gildea, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 4:49 ` Eli Zaretskii
@ 2002-04-29 5:37 ` Andrew Choi
2002-04-29 13:32 ` Stefan Monnier
2002-04-30 5:18 ` Richard Stallman
2002-04-29 18:40 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Andrew Choi @ 2002-04-29 5:37 UTC (permalink / raw
Cc: rms, gildea, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 4:54 ` Eli Zaretskii
@ 2002-04-29 13:02 ` Stefan Monnier
2002-04-29 18:38 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-04-29 13:02 UTC (permalink / raw
Cc: Stefan Monnier, gildea, emacs-devel
>
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 5:37 ` Andrew Choi
@ 2002-04-29 13:32 ` Stefan Monnier
2002-04-29 13:46 ` Andrew Choi
2002-04-30 5:18 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-04-29 13:32 UTC (permalink / raw
Cc: eliz, rms, gildea, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 13:32 ` Stefan Monnier
@ 2002-04-29 13:46 ` Andrew Choi
0 siblings, 0 replies; 1364+ messages in thread
From: Andrew Choi @ 2002-04-29 13:46 UTC (permalink / raw
Cc: eliz, rms, gildea, emacs-devel
> > 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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 13:02 ` Stefan Monnier
@ 2002-04-29 18:38 ` Eli Zaretskii
2002-04-30 5:19 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-04-29 18:38 UTC (permalink / raw
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 4:49 ` Eli Zaretskii
2002-04-29 5:37 ` Andrew Choi
@ 2002-04-29 18:40 ` Richard Stallman
2002-04-29 19:13 ` Eli Zaretskii
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-04-29 18:40 UTC (permalink / raw
Cc: gildea, emacs-devel, akochoi
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 18:40 ` Richard Stallman
@ 2002-04-29 19:13 ` Eli Zaretskii
2002-04-29 19:41 ` Stefan Monnier
2002-04-30 21:19 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-04-29 19:13 UTC (permalink / raw
Cc: gildea, emacs-devel, akochoi
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 19:13 ` Eli Zaretskii
@ 2002-04-29 19:41 ` Stefan Monnier
2002-04-30 4:51 ` Eli Zaretskii
2002-04-30 21:19 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-04-29 19:41 UTC (permalink / raw
Cc: rms, gildea, emacs-devel, akochoi
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 19:41 ` Stefan Monnier
@ 2002-04-30 4:51 ` Eli Zaretskii
0 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-04-30 4:51 UTC (permalink / raw
Cc: rms, gildea, emacs-devel, akochoi
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*.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 5:37 ` Andrew Choi
2002-04-29 13:32 ` Stefan Monnier
@ 2002-04-30 5:18 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-04-30 5:18 UTC (permalink / raw
Cc: eliz, gildea, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 18:38 ` Eli Zaretskii
@ 2002-04-30 5:19 ` Richard Stallman
2002-04-30 5:39 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-04-30 5:19 UTC (permalink / raw
Cc: gildea, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-30 5:19 ` Richard Stallman
@ 2002-04-30 5:39 ` Eli Zaretskii
0 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-04-30 5:39 UTC (permalink / raw
Cc: gildea, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: decode_eol and inconsistent EOL
2002-04-29 19:13 ` Eli Zaretskii
2002-04-29 19:41 ` Stefan Monnier
@ 2002-04-30 21:19 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-04-30 21:19 UTC (permalink / raw
Cc: gildea, emacs-devel, akochoi
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Integrate Tramp
@ 2002-06-16 21:23 Kai Großjohann
2002-06-17 2:44 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-16 21:23 UTC (permalink / raw
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-16 21:23 Integrate Tramp Kai Großjohann
@ 2002-06-17 2:44 ` Miles Bader
2002-06-17 11:19 ` Kai Großjohann
2002-06-17 4:44 ` Eli Zaretskii
2002-06-17 16:31 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-06-17 2:44 UTC (permalink / raw
Cc: emacs-devel
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-16 21:23 Integrate Tramp Kai Großjohann
2002-06-17 2:44 ` Miles Bader
@ 2002-06-17 4:44 ` Eli Zaretskii
2002-06-17 11:20 ` Kai Großjohann
2002-06-17 16:31 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-06-17 4:44 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-17 2:44 ` Miles Bader
@ 2002-06-17 11:19 ` Kai Großjohann
2002-06-17 13:04 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-17 11:19 UTC (permalink / raw
Cc: emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-17 4:44 ` Eli Zaretskii
@ 2002-06-17 11:20 ` Kai Großjohann
0 siblings, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-17 11:20 UTC (permalink / raw
Cc: emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-17 11:19 ` Kai Großjohann
@ 2002-06-17 13:04 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-17 13:04 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-16 21:23 Integrate Tramp Kai Großjohann
2002-06-17 2:44 ` Miles Bader
2002-06-17 4:44 ` Eli Zaretskii
@ 2002-06-17 16:31 ` Richard Stallman
2002-06-17 16:44 ` Kai Großjohann
2 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-06-17 16:31 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-17 16:31 ` Richard Stallman
@ 2002-06-17 16:44 ` Kai Großjohann
2002-06-17 18:19 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-17 16:44 UTC (permalink / raw
Cc: emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-17 16:44 ` Kai Großjohann
@ 2002-06-17 18:19 ` Eli Zaretskii
2002-06-18 9:56 ` Kai Großjohann
2002-06-18 5:05 ` Eli Zaretskii
2002-06-19 2:23 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-06-17 18:19 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-17 16:44 ` Kai Großjohann
2002-06-17 18:19 ` Eli Zaretskii
@ 2002-06-18 5:05 ` Eli Zaretskii
2002-06-18 9:56 ` Kai Großjohann
2002-06-19 2:23 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-06-18 5:05 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-17 18:19 ` Eli Zaretskii
@ 2002-06-18 9:56 ` Kai Großjohann
2002-06-18 11:24 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-18 9:56 UTC (permalink / raw
Cc: emacs-devel
"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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-18 5:05 ` Eli Zaretskii
@ 2002-06-18 9:56 ` Kai Großjohann
0 siblings, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-18 9:56 UTC (permalink / raw
Cc: emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-18 9:56 ` Kai Großjohann
@ 2002-06-18 11:24 ` Kim F. Storm
2002-06-18 11:29 ` Kai Großjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-06-18 11:24 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-18 11:24 ` Kim F. Storm
@ 2002-06-18 11:29 ` Kai Großjohann
0 siblings, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-18 11:29 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-17 16:44 ` Kai Großjohann
2002-06-17 18:19 ` Eli Zaretskii
2002-06-18 5:05 ` Eli Zaretskii
@ 2002-06-19 2:23 ` Richard Stallman
2002-06-19 2:46 ` Miles Bader
` (2 more replies)
2 siblings, 3 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-19 2:23 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 2:23 ` Richard Stallman
@ 2002-06-19 2:46 ` Miles Bader
2002-06-19 12:40 ` Kim F. Storm
2002-06-20 14:34 ` Richard Stallman
2002-06-19 8:42 ` Ehud Karni
2002-06-19 12:45 ` Kim F. Storm
2 siblings, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-19 2:46 UTC (permalink / raw
Cc: Kai.Grossjohann, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 2:23 ` Richard Stallman
2002-06-19 2:46 ` Miles Bader
@ 2002-06-19 8:42 ` Ehud Karni
2002-06-19 12:45 ` Kim F. Storm
2 siblings, 0 replies; 1364+ messages in thread
From: Ehud Karni @ 2002-06-19 8:42 UTC (permalink / raw
Cc: Kai.Grossjohann, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 2:46 ` Miles Bader
@ 2002-06-19 12:40 ` Kim F. Storm
2002-06-21 9:40 ` Richard Stallman
2002-06-20 14:34 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-06-19 12:40 UTC (permalink / raw
Cc: rms, Kai.Grossjohann, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 2:23 ` Richard Stallman
2002-06-19 2:46 ` Miles Bader
2002-06-19 8:42 ` Ehud Karni
@ 2002-06-19 12:45 ` Kim F. Storm
2002-06-19 15:00 ` Stefan Monnier
` (2 more replies)
2 siblings, 3 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-06-19 12:45 UTC (permalink / raw
Cc: Kai.Grossjohann, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 12:45 ` Kim F. Storm
@ 2002-06-19 15:00 ` Stefan Monnier
2002-06-19 21:34 ` Kim F. Storm
2002-06-19 15:20 ` Robert J. Chassell
2002-06-21 9:40 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-06-19 15:00 UTC (permalink / raw
Cc: rms, Kai.Grossjohann, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 12:45 ` Kim F. Storm
2002-06-19 15:00 ` Stefan Monnier
@ 2002-06-19 15:20 ` Robert J. Chassell
2002-06-21 9:40 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-19 15:20 UTC (permalink / raw
Cc: rms, Kai.Grossjohann, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 15:00 ` Stefan Monnier
@ 2002-06-19 21:34 ` Kim F. Storm
2002-06-19 22:35 ` Stefan Monnier
2002-06-20 8:29 ` Kai Großjohann
0 siblings, 2 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-06-19 21:34 UTC (permalink / raw
Cc: Kai.Grossjohann, emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 21:34 ` Kim F. Storm
@ 2002-06-19 22:35 ` Stefan Monnier
2002-06-21 9:41 ` Richard Stallman
2002-06-20 8:29 ` Kai Großjohann
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-06-19 22:35 UTC (permalink / raw
Cc: Stefan Monnier, Kai.Grossjohann, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 21:34 ` Kim F. Storm
2002-06-19 22:35 ` Stefan Monnier
@ 2002-06-20 8:29 ` Kai Großjohann
2002-06-21 9:42 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-20 8:29 UTC (permalink / raw
Cc: Stefan Monnier, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 2:46 ` Miles Bader
2002-06-19 12:40 ` Kim F. Storm
@ 2002-06-20 14:34 ` Richard Stallman
2002-06-20 15:51 ` Kai Großjohann
2002-06-20 16:11 ` Kai Großjohann
1 sibling, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-20 14:34 UTC (permalink / raw
Cc: Kai.Grossjohann, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
@ 2002-06-20 14:35 Richard Stallman
2002-06-20 15:55 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-06-20 14:35 UTC (permalink / raw
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 -------
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 14:34 ` Richard Stallman
@ 2002-06-20 15:51 ` Kai Großjohann
2002-06-20 19:48 ` Miles Bader
2002-06-21 16:29 ` Richard Stallman
2002-06-20 16:11 ` Kai Großjohann
1 sibling, 2 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-20 15:51 UTC (permalink / raw
Cc: miles, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-20 14:35 [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye] Richard Stallman
@ 2002-06-20 15:55 ` Robert J. Chassell
2002-06-20 23:27 ` Kim F. Storm
2002-06-21 16:29 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-20 15:55 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 14:34 ` Richard Stallman
2002-06-20 15:51 ` Kai Großjohann
@ 2002-06-20 16:11 ` Kai Großjohann
2002-06-20 16:31 ` Stefan Monnier
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-20 16:11 UTC (permalink / raw
Cc: miles, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 16:11 ` Kai Großjohann
@ 2002-06-20 16:31 ` Stefan Monnier
2002-06-20 16:40 ` Robert J. Chassell
2002-06-20 16:41 ` Kai Großjohann
2 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-06-20 16:31 UTC (permalink / raw
Cc: rms, miles, emacs-devel, wmperry
> /[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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 16:11 ` Kai Großjohann
2002-06-20 16:31 ` Stefan Monnier
@ 2002-06-20 16:40 ` Robert J. Chassell
2002-06-20 23:02 ` Kim F. Storm
2002-06-20 16:41 ` Kai Großjohann
2 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-20 16:40 UTC (permalink / raw
Cc: rms, miles, emacs-devel
... 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 16:11 ` Kai Großjohann
2002-06-20 16:31 ` Stefan Monnier
2002-06-20 16:40 ` Robert J. Chassell
@ 2002-06-20 16:41 ` Kai Großjohann
2002-06-21 13:53 ` Robert J. Chassell
2 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-20 16:41 UTC (permalink / raw
Cc: miles, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 15:51 ` Kai Großjohann
@ 2002-06-20 19:48 ` Miles Bader
2002-06-21 16:29 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-20 19:48 UTC (permalink / raw
Cc: rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 23:02 ` Kim F. Storm
@ 2002-06-20 22:08 ` Miles Bader
2002-06-20 22:20 ` Robert J. Chassell
` (2 subsequent siblings)
3 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-20 22:08 UTC (permalink / raw
Cc: bob, Kai.Grossjohann, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 23:02 ` Kim F. Storm
2002-06-20 22:08 ` Miles Bader
@ 2002-06-20 22:20 ` Robert J. Chassell
2002-06-21 7:31 ` Kai Großjohann
2002-06-21 12:38 ` Kai Großjohann
3 siblings, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-20 22:20 UTC (permalink / raw
... 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 16:40 ` Robert J. Chassell
@ 2002-06-20 23:02 ` Kim F. Storm
2002-06-20 22:08 ` Miles Bader
` (3 more replies)
0 siblings, 4 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-06-20 23:02 UTC (permalink / raw
Cc: Kai.Grossjohann, rms, miles, emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-20 15:55 ` Robert J. Chassell
@ 2002-06-20 23:27 ` Kim F. Storm
2002-06-21 20:37 ` Robert J. Chassell
2002-06-21 16:29 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-06-20 23:27 UTC (permalink / raw
Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 23:02 ` Kim F. Storm
2002-06-20 22:08 ` Miles Bader
2002-06-20 22:20 ` Robert J. Chassell
@ 2002-06-21 7:31 ` Kai Großjohann
2002-06-21 7:45 ` Miles Bader
2002-06-21 12:38 ` Kai Großjohann
3 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 7:31 UTC (permalink / raw
Cc: bob, rms, miles, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 7:31 ` Kai Großjohann
@ 2002-06-21 7:45 ` Miles Bader
2002-06-21 12:36 ` Kai Großjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-06-21 7:45 UTC (permalink / raw
Cc: Kim F. Storm, bob, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 12:40 ` Kim F. Storm
@ 2002-06-21 9:40 ` Richard Stallman
2002-06-21 12:29 ` Kai Großjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-06-21 9:40 UTC (permalink / raw
Cc: miles, Kai.Grossjohann, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 12:45 ` Kim F. Storm
2002-06-19 15:00 ` Stefan Monnier
2002-06-19 15:20 ` Robert J. Chassell
@ 2002-06-21 9:40 ` Richard Stallman
2002-06-21 9:48 ` Andreas Schwab
2002-06-21 12:12 ` Kai Großjohann
2 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-21 9:40 UTC (permalink / raw
Cc: Kai.Grossjohann, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-19 22:35 ` Stefan Monnier
@ 2002-06-21 9:41 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-21 9:41 UTC (permalink / raw
Cc: storm, monnier+gnu/emacs, Kai.Grossjohann, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 8:29 ` Kai Großjohann
@ 2002-06-21 9:42 ` Richard Stallman
2002-06-21 9:49 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-21 9:42 UTC (permalink / raw
Cc: storm, monnier+gnu/emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 9:40 ` Richard Stallman
@ 2002-06-21 9:48 ` Andreas Schwab
2002-06-21 12:12 ` Kai Großjohann
1 sibling, 0 replies; 1364+ messages in thread
From: Andreas Schwab @ 2002-06-21 9:48 UTC (permalink / raw
Cc: storm, Kai.Grossjohann, emacs-devel
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 9:42 ` Richard Stallman
@ 2002-06-21 9:49 ` Miles Bader
2002-06-21 13:33 ` Jon Cast
2002-06-21 14:37 ` Miles Bader
2002-06-21 19:30 ` Stefan Monnier
2 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-06-21 9:49 UTC (permalink / raw
Cc: Kai.Grossjohann, storm, monnier+gnu/emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 9:40 ` Richard Stallman
2002-06-21 9:48 ` Andreas Schwab
@ 2002-06-21 12:12 ` Kai Großjohann
2002-06-21 14:23 ` Mario Lang
1 sibling, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 12:12 UTC (permalink / raw
Cc: storm, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 9:40 ` Richard Stallman
@ 2002-06-21 12:29 ` Kai Großjohann
2002-06-21 15:22 ` Robert J. Chassell
2002-06-22 6:59 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 12:29 UTC (permalink / raw
Cc: storm, miles, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 7:45 ` Miles Bader
@ 2002-06-21 12:36 ` Kai Großjohann
0 siblings, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 12:36 UTC (permalink / raw
Cc: Kim F. Storm, bob, rms, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 23:02 ` Kim F. Storm
` (2 preceding siblings ...)
2002-06-21 7:31 ` Kai Großjohann
@ 2002-06-21 12:38 ` Kai Großjohann
2002-06-21 13:23 ` Miles Bader
3 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 12:38 UTC (permalink / raw
Cc: bob, rms, miles, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 12:38 ` Kai Großjohann
@ 2002-06-21 13:23 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-21 13:23 UTC (permalink / raw
Cc: Kim F. Storm, bob, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 9:49 ` Miles Bader
@ 2002-06-21 13:33 ` Jon Cast
2002-06-21 14:25 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-06-21 13:33 UTC (permalink / raw
Cc: rms, Kai.Grossjohann, storm, monnier+gnu/emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 16:41 ` Kai Großjohann
@ 2002-06-21 13:53 ` Robert J. Chassell
2002-06-21 14:23 ` Kai Großjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-21 13:53 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 13:53 ` Robert J. Chassell
@ 2002-06-21 14:23 ` Kai Großjohann
2002-06-21 14:55 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 14:23 UTC (permalink / raw
Cc: rms, miles, emacs-devel
"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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 12:12 ` Kai Großjohann
@ 2002-06-21 14:23 ` Mario Lang
0 siblings, 0 replies; 1364+ messages in thread
From: Mario Lang @ 2002-06-21 14:23 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 13:33 ` Jon Cast
@ 2002-06-21 14:25 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-21 14:25 UTC (permalink / raw
Cc: rms, Kai.Grossjohann, storm, monnier+gnu/emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 9:42 ` Richard Stallman
2002-06-21 9:49 ` Miles Bader
@ 2002-06-21 14:37 ` Miles Bader
2002-06-22 6:59 ` Richard Stallman
2002-06-21 19:30 ` Stefan Monnier
2 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-06-21 14:37 UTC (permalink / raw
Cc: Kai.Grossjohann, storm, monnier+gnu/emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 14:23 ` Kai Großjohann
@ 2002-06-21 14:55 ` Robert J. Chassell
2002-06-21 15:50 ` Kai Großjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-21 14:55 UTC (permalink / raw
Cc: rms, miles, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 12:29 ` Kai Großjohann
@ 2002-06-21 15:22 ` Robert J. Chassell
2002-06-21 16:09 ` Kai Großjohann
2002-06-22 6:59 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-21 15:22 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 14:55 ` Robert J. Chassell
@ 2002-06-21 15:50 ` Kai Großjohann
2002-06-21 20:30 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 15:50 UTC (permalink / raw
Cc: rms, miles, emacs-devel
"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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 15:22 ` Robert J. Chassell
@ 2002-06-21 16:09 ` Kai Großjohann
2002-06-21 20:21 ` Robert J. Chassell
2002-06-22 22:51 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 16:09 UTC (permalink / raw
Cc: emacs-devel
"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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-20 15:51 ` Kai Großjohann
2002-06-20 19:48 ` Miles Bader
@ 2002-06-21 16:29 ` Richard Stallman
2002-06-21 19:34 ` Andreas Schwab
2002-06-21 20:52 ` Kai Großjohann
1 sibling, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-21 16:29 UTC (permalink / raw
Cc: miles, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-20 15:55 ` Robert J. Chassell
2002-06-20 23:27 ` Kim F. Storm
@ 2002-06-21 16:29 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-21 16:29 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 9:42 ` Richard Stallman
2002-06-21 9:49 ` Miles Bader
2002-06-21 14:37 ` Miles Bader
@ 2002-06-21 19:30 ` Stefan Monnier
2 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-06-21 19:30 UTC (permalink / raw
Cc: Kai.Grossjohann, storm, monnier+gnu/emacs, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 16:29 ` Richard Stallman
@ 2002-06-21 19:34 ` Andreas Schwab
2002-06-21 20:52 ` Kai Großjohann
1 sibling, 0 replies; 1364+ messages in thread
From: Andreas Schwab @ 2002-06-21 19:34 UTC (permalink / raw
Cc: Kai.Grossjohann, miles, emacs-devel
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 16:09 ` Kai Großjohann
@ 2002-06-21 20:21 ` Robert J. Chassell
2002-06-21 21:18 ` Kai Großjohann
2002-06-22 22:51 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-21 20:21 UTC (permalink / raw
... 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 15:50 ` Kai Großjohann
@ 2002-06-21 20:30 ` Robert J. Chassell
0 siblings, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-21 20:30 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-20 23:27 ` Kim F. Storm
@ 2002-06-21 20:37 ` Robert J. Chassell
2002-06-22 17:20 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2002-06-21 20:37 UTC (permalink / raw
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 16:29 ` Richard Stallman
2002-06-21 19:34 ` Andreas Schwab
@ 2002-06-21 20:52 ` Kai Großjohann
2002-06-22 17:25 ` Stefan Monnier
2002-06-22 22:51 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 20:52 UTC (permalink / raw
Cc: miles, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 20:21 ` Robert J. Chassell
@ 2002-06-21 21:18 ` Kai Großjohann
2002-06-22 22:51 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-21 21:18 UTC (permalink / raw
Cc: emacs-devel
"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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 12:29 ` Kai Großjohann
2002-06-21 15:22 ` Robert J. Chassell
@ 2002-06-22 6:59 ` Richard Stallman
2002-06-22 10:14 ` Kai Großjohann
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-06-22 6:59 UTC (permalink / raw
Cc: storm, miles, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 14:37 ` Miles Bader
@ 2002-06-22 6:59 ` Richard Stallman
2002-06-22 7:21 ` Michael Kifer
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-06-22 6:59 UTC (permalink / raw
Cc: Kai.Grossjohann, storm, monnier+gnu/emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-22 6:59 ` Richard Stallman
@ 2002-06-22 7:21 ` Michael Kifer
2002-06-22 7:25 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Michael Kifer @ 2002-06-22 7:21 UTC (permalink / raw
Cc: miles, Kai.Grossjohann, storm, monnier+gnu/emacs, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-22 7:21 ` Michael Kifer
@ 2002-06-22 7:25 ` Miles Bader
2002-06-22 9:41 ` Kai Großjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-06-22 7:25 UTC (permalink / raw
Cc: rms, Kai.Grossjohann, storm, monnier+gnu/emacs, emacs-devel
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....
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-22 7:25 ` Miles Bader
@ 2002-06-22 9:41 ` Kai Großjohann
2002-06-22 12:43 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-22 9:41 UTC (permalink / raw
Cc: Michael Kifer, rms, storm, monnier+gnu/emacs, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-22 6:59 ` Richard Stallman
@ 2002-06-22 10:14 ` Kai Großjohann
2002-06-22 17:46 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-22 10:14 UTC (permalink / raw
Cc: storm, miles, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-22 9:41 ` Kai Großjohann
@ 2002-06-22 12:43 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-22 12:43 UTC (permalink / raw
Cc: Michael Kifer, rms, storm, monnier+gnu/emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-21 20:37 ` Robert J. Chassell
@ 2002-06-22 17:20 ` Stefan Monnier
2002-06-22 19:30 ` Alex Schroeder
2002-06-23 18:12 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-06-22 17:20 UTC (permalink / raw
Cc: emacs-devel
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 20:52 ` Kai Großjohann
@ 2002-06-22 17:25 ` Stefan Monnier
2002-06-22 22:51 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-06-22 17:25 UTC (permalink / raw
Cc: rms, miles, emacs-devel
> > * 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-22 10:14 ` Kai Großjohann
@ 2002-06-22 17:46 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-06-22 17:46 UTC (permalink / raw
Cc: rms, storm, miles, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-22 17:20 ` Stefan Monnier
@ 2002-06-22 19:30 ` Alex Schroeder
2002-06-22 20:12 ` Stefan Monnier
2002-06-23 18:12 ` Richard Stallman
2002-06-23 18:12 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Alex Schroeder @ 2002-06-22 19:30 UTC (permalink / raw
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-22 19:30 ` Alex Schroeder
@ 2002-06-22 20:12 ` Stefan Monnier
2002-06-23 4:57 ` Eli Zaretskii
2002-06-23 18:12 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-06-22 20:12 UTC (permalink / raw
Cc: emacs-devel
> "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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 20:52 ` Kai Großjohann
2002-06-22 17:25 ` Stefan Monnier
@ 2002-06-22 22:51 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-22 22:51 UTC (permalink / raw
Cc: miles, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 21:18 ` Kai Großjohann
@ 2002-06-22 22:51 ` Richard Stallman
2002-06-23 16:07 ` Kai Großjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-06-22 22:51 UTC (permalink / raw
Cc: bob, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-21 16:09 ` Kai Großjohann
2002-06-21 20:21 ` Robert J. Chassell
@ 2002-06-22 22:51 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-22 22:51 UTC (permalink / raw
Cc: bob, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-22 20:12 ` Stefan Monnier
@ 2002-06-23 4:57 ` Eli Zaretskii
2002-06-24 9:33 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-06-23 4:57 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Integrate Tramp
2002-06-22 22:51 ` Richard Stallman
@ 2002-06-23 16:07 ` Kai Großjohann
0 siblings, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-06-23 16:07 UTC (permalink / raw
Cc: bob, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-22 17:20 ` Stefan Monnier
2002-06-22 19:30 ` Alex Schroeder
@ 2002-06-23 18:12 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-23 18:12 UTC (permalink / raw
Cc: bob, emacs-devel
[-- 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-22 19:30 ` Alex Schroeder
2002-06-22 20:12 ` Stefan Monnier
@ 2002-06-23 18:12 ` Richard Stallman
2002-06-24 7:41 ` Alex Schroeder
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-06-23 18:12 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-23 18:12 ` Richard Stallman
@ 2002-06-24 7:41 ` Alex Schroeder
2002-06-24 19:40 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Alex Schroeder @ 2002-06-24 7:41 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-23 4:57 ` Eli Zaretskii
@ 2002-06-24 9:33 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-24 9:33 UTC (permalink / raw
Cc: monnier+gnu/emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 7:41 ` Alex Schroeder
@ 2002-06-24 19:40 ` Richard Stallman
2002-06-24 21:17 ` Alex Schroeder
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-06-24 19:40 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 19:40 ` Richard Stallman
@ 2002-06-24 21:17 ` Alex Schroeder
2002-06-24 21:36 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Alex Schroeder @ 2002-06-24 21:17 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 21:17 ` Alex Schroeder
@ 2002-06-24 21:36 ` Miles Bader
2002-06-24 22:01 ` Alex Schroeder
2002-06-24 22:47 ` Paul Stoeber
0 siblings, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-24 21:36 UTC (permalink / raw
Cc: emacs-devel
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'
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 21:36 ` Miles Bader
@ 2002-06-24 22:01 ` Alex Schroeder
2002-06-24 22:59 ` Miles Bader
2002-06-24 23:49 ` Jon Cast
2002-06-24 22:47 ` Paul Stoeber
1 sibling, 2 replies; 1364+ messages in thread
From: Alex Schroeder @ 2002-06-24 22:01 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 21:36 ` Miles Bader
2002-06-24 22:01 ` Alex Schroeder
@ 2002-06-24 22:47 ` Paul Stoeber
1 sibling, 0 replies; 1364+ messages in thread
From: Paul Stoeber @ 2002-06-24 22:47 UTC (permalink / raw
Cc: jidanni
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 22:01 ` Alex Schroeder
@ 2002-06-24 22:59 ` Miles Bader
2002-06-25 13:54 ` Francesco Potorti`
2002-06-24 23:49 ` Jon Cast
1 sibling, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-06-24 22:59 UTC (permalink / raw
Cc: emacs-devel
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'
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 22:01 ` Alex Schroeder
2002-06-24 22:59 ` Miles Bader
@ 2002-06-24 23:49 ` Jon Cast
2002-06-25 0:16 ` Miles Bader
1 sibling, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-06-24 23:49 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 23:49 ` Jon Cast
@ 2002-06-25 0:16 ` Miles Bader
2002-06-25 1:49 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-06-25 0:16 UTC (permalink / raw
Cc: Alex Schroeder, emacs-devel
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'
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-25 0:16 ` Miles Bader
@ 2002-06-25 1:49 ` Jon Cast
2002-06-25 2:11 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-06-25 1:49 UTC (permalink / raw
Cc: Alex Schroeder, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-25 1:49 ` Jon Cast
@ 2002-06-25 2:11 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-25 2:11 UTC (permalink / raw
Cc: Alex Schroeder, emacs-devel
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-24 22:59 ` Miles Bader
@ 2002-06-25 13:54 ` Francesco Potorti`
2002-06-25 14:07 ` Werner LEMBERG
2002-06-26 22:24 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Francesco Potorti` @ 2002-06-25 13:54 UTC (permalink / raw
Cc: Alex Schroeder, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-25 13:54 ` Francesco Potorti`
@ 2002-06-25 14:07 ` Werner LEMBERG
2002-06-26 22:24 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Werner LEMBERG @ 2002-06-25 14:07 UTC (permalink / raw
Cc: miles, alex, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-25 13:54 ` Francesco Potorti`
2002-06-25 14:07 ` Werner LEMBERG
@ 2002-06-26 22:24 ` Richard Stallman
2002-06-27 2:33 ` Miles Bader
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-26 22:24 UTC (permalink / raw
Cc: miles, alex, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-26 22:24 ` Richard Stallman
@ 2002-06-27 2:33 ` Miles Bader
2002-06-28 14:33 ` Alex Schroeder
` (2 more replies)
2002-06-27 6:49 ` Juanma Barranquero
2002-06-27 8:07 ` Francesco Potorti`
2 siblings, 3 replies; 1364+ messages in thread
From: Miles Bader @ 2002-06-27 2:33 UTC (permalink / raw
Cc: pot, alex, emacs-devel
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....
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-26 22:24 ` Richard Stallman
2002-06-27 2:33 ` Miles Bader
@ 2002-06-27 6:49 ` Juanma Barranquero
2002-06-27 8:07 ` Francesco Potorti`
2 siblings, 0 replies; 1364+ messages in thread
From: Juanma Barranquero @ 2002-06-27 6:49 UTC (permalink / raw
Cc: pot, miles, alex, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-26 22:24 ` Richard Stallman
2002-06-27 2:33 ` Miles Bader
2002-06-27 6:49 ` Juanma Barranquero
@ 2002-06-27 8:07 ` Francesco Potorti`
2002-06-28 17:38 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Francesco Potorti` @ 2002-06-27 8:07 UTC (permalink / raw
Cc: emacs-devel, alex, miles
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-27 2:33 ` Miles Bader
@ 2002-06-28 14:33 ` Alex Schroeder
2002-06-29 22:21 ` Richard Stallman
2002-06-28 17:41 ` Richard Stallman
2002-06-30 6:33 ` Eli Zaretskii
2 siblings, 1 reply; 1364+ messages in thread
From: Alex Schroeder @ 2002-06-28 14:33 UTC (permalink / raw
Cc: rms, pot, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-27 8:07 ` Francesco Potorti`
@ 2002-06-28 17:38 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-28 17:38 UTC (permalink / raw
Cc: emacs-devel, alex, miles
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-27 2:33 ` Miles Bader
2002-06-28 14:33 ` Alex Schroeder
@ 2002-06-28 17:41 ` Richard Stallman
2002-06-30 6:33 ` Eli Zaretskii
2 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-28 17:41 UTC (permalink / raw
Cc: pot, alex, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* No calc in pretest?
@ 2002-06-29 20:28 Kevin A. Burton
2002-06-30 6:24 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Kevin A. Burton @ 2002-06-29 20:28 UTC (permalink / raw
-----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-----
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-28 14:33 ` Alex Schroeder
@ 2002-06-29 22:21 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-06-29 22:21 UTC (permalink / raw
Cc: miles, pot, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-06-29 20:28 No calc in pretest? Kevin A. Burton
@ 2002-06-30 6:24 ` Eli Zaretskii
2002-06-30 6:44 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-06-30 6:24 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]
2002-06-27 2:33 ` Miles Bader
2002-06-28 14:33 ` Alex Schroeder
2002-06-28 17:41 ` Richard Stallman
@ 2002-06-30 6:33 ` Eli Zaretskii
2 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-06-30 6:33 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-06-30 6:24 ` Eli Zaretskii
@ 2002-06-30 6:44 ` Jon Cast
2002-06-30 9:23 ` Eli Zaretskii
2002-07-01 21:32 ` Francesco Potorti`
0 siblings, 2 replies; 1364+ messages in thread
From: Jon Cast @ 2002-06-30 6:44 UTC (permalink / raw
Cc: burton, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-06-30 6:44 ` Jon Cast
@ 2002-06-30 9:23 ` Eli Zaretskii
2002-06-30 19:06 ` Simon Josefsson
` (2 more replies)
2002-07-01 21:32 ` Francesco Potorti`
1 sibling, 3 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-06-30 9:23 UTC (permalink / raw
Cc: burton, Emacs Devel Mailing List
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.]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-06-30 9:23 ` Eli Zaretskii
@ 2002-06-30 19:06 ` Simon Josefsson
2002-07-02 20:22 ` Jon Cast
2002-07-01 1:55 ` Miles Bader
2002-07-02 15:09 ` Stefan Monnier
2 siblings, 1 reply; 1364+ messages in thread
From: Simon Josefsson @ 2002-06-30 19:06 UTC (permalink / raw
Cc: Jon Cast, burton, Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-06-30 9:23 ` Eli Zaretskii
2002-06-30 19:06 ` Simon Josefsson
@ 2002-07-01 1:55 ` Miles Bader
2002-07-01 5:13 ` Eli Zaretskii
2002-07-02 15:09 ` Stefan Monnier
2 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-07-01 1:55 UTC (permalink / raw
Cc: Jon Cast, burton, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-01 1:55 ` Miles Bader
@ 2002-07-01 5:13 ` Eli Zaretskii
0 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-01 5:13 UTC (permalink / raw
Cc: Jon Cast, burton, Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-06-30 6:44 ` Jon Cast
2002-06-30 9:23 ` Eli Zaretskii
@ 2002-07-01 21:32 ` Francesco Potorti`
2002-07-02 8:49 ` Kim F. Storm
1 sibling, 1 reply; 1364+ messages in thread
From: Francesco Potorti` @ 2002-07-01 21:32 UTC (permalink / raw
Cc: Eli Zaretskii, burton, Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 8:49 ` Kim F. Storm
@ 2002-07-02 8:06 ` Miles Bader
2002-07-02 9:30 ` Kai Großjohann
` (2 more replies)
2002-07-02 10:08 ` Eli Zaretskii
2002-07-02 20:30 ` Jon Cast
2 siblings, 3 replies; 1364+ messages in thread
From: Miles Bader @ 2002-07-02 8:06 UTC (permalink / raw
Cc: Francesco Potorti`, Jon Cast, Eli Zaretskii, burton,
Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-01 21:32 ` Francesco Potorti`
@ 2002-07-02 8:49 ` Kim F. Storm
2002-07-02 8:06 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-02 8:49 UTC (permalink / raw
Cc: Jon Cast, Eli Zaretskii, burton, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 8:06 ` Miles Bader
@ 2002-07-02 9:30 ` Kai Großjohann
2002-07-02 9:43 ` Kim F. Storm
2002-07-02 10:10 ` Eli Zaretskii
2 siblings, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-07-02 9:30 UTC (permalink / raw
Cc: Kim F. Storm, Francesco Potorti`, Jon Cast, Eli Zaretskii, burton,
Emacs Devel Mailing List
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 8:06 ` Miles Bader
2002-07-02 9:30 ` Kai Großjohann
@ 2002-07-02 9:43 ` Kim F. Storm
2002-07-02 9:50 ` Juanma Barranquero
` (3 more replies)
2002-07-02 10:10 ` Eli Zaretskii
2 siblings, 4 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-02 9:43 UTC (permalink / raw
Cc: Francesco Potorti`, Jon Cast, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 9:43 ` Kim F. Storm
@ 2002-07-02 9:50 ` Juanma Barranquero
2002-07-02 20:44 ` Jon Cast
2002-07-02 10:11 ` Eli Zaretskii
` (2 subsequent siblings)
3 siblings, 1 reply; 1364+ messages in thread
From: Juanma Barranquero @ 2002-07-02 9:50 UTC (permalink / raw
Cc: Miles Bader, Francesco Potorti`, Jon Cast, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 8:49 ` Kim F. Storm
2002-07-02 8:06 ` Miles Bader
@ 2002-07-02 10:08 ` Eli Zaretskii
2002-07-02 15:28 ` Stefan Monnier
2002-07-03 20:57 ` Richard Stallman
2002-07-02 20:30 ` Jon Cast
2 siblings, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-02 10:08 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 8:06 ` Miles Bader
2002-07-02 9:30 ` Kai Großjohann
2002-07-02 9:43 ` Kim F. Storm
@ 2002-07-02 10:10 ` Eli Zaretskii
2 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-02 10:10 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 9:43 ` Kim F. Storm
2002-07-02 9:50 ` Juanma Barranquero
@ 2002-07-02 10:11 ` Eli Zaretskii
2002-07-02 20:38 ` Jon Cast
2002-07-03 20:57 ` Richard Stallman
3 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-02 10:11 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-06-30 9:23 ` Eli Zaretskii
2002-06-30 19:06 ` Simon Josefsson
2002-07-01 1:55 ` Miles Bader
@ 2002-07-02 15:09 ` Stefan Monnier
2002-07-02 15:20 ` Miles Bader
2002-07-02 19:41 ` Jon Cast
2 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 15:09 UTC (permalink / raw
Cc: Jon Cast, burton, Emacs Devel Mailing List
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 15:09 ` Stefan Monnier
@ 2002-07-02 15:20 ` Miles Bader
2002-07-02 19:41 ` Jon Cast
1 sibling, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-07-02 15:20 UTC (permalink / raw
Cc: Eli Zaretskii, Jon Cast, burton, Emacs Devel Mailing List
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 10:08 ` Eli Zaretskii
@ 2002-07-02 15:28 ` Stefan Monnier
2002-07-02 15:58 ` Miles Bader
2002-07-02 19:52 ` Jon Cast
2002-07-03 20:57 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 15:28 UTC (permalink / raw
Cc: storm, Emacs Devel Mailing List
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 15:28 ` Stefan Monnier
@ 2002-07-02 15:58 ` Miles Bader
2002-07-02 16:05 ` Stefan Monnier
2002-07-02 16:09 ` Simon Josefsson
2002-07-02 19:52 ` Jon Cast
1 sibling, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2002-07-02 15:58 UTC (permalink / raw
Cc: Eli Zaretskii, storm, Emacs Devel Mailing List
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 15:58 ` Miles Bader
@ 2002-07-02 16:05 ` Stefan Monnier
2002-07-02 16:23 ` Miles Bader
2002-07-02 19:56 ` Jon Cast
2002-07-02 16:09 ` Simon Josefsson
1 sibling, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 16:05 UTC (permalink / raw
Cc: Stefan Monnier, Eli Zaretskii, storm, Emacs Devel Mailing List
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 15:58 ` Miles Bader
2002-07-02 16:05 ` Stefan Monnier
@ 2002-07-02 16:09 ` Simon Josefsson
2002-07-02 16:40 ` Eli Zaretskii
2002-07-02 20:05 ` Jon Cast
1 sibling, 2 replies; 1364+ messages in thread
From: Simon Josefsson @ 2002-07-02 16:09 UTC (permalink / raw
Cc: Stefan Monnier, Eli Zaretskii, storm, Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:05 ` Stefan Monnier
@ 2002-07-02 16:23 ` Miles Bader
2002-07-02 16:26 ` Stefan Monnier
2002-07-02 19:56 ` Jon Cast
1 sibling, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-07-02 16:23 UTC (permalink / raw
Cc: Eli Zaretskii, storm, Emacs Devel Mailing List
"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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:23 ` Miles Bader
@ 2002-07-02 16:26 ` Stefan Monnier
2002-07-02 16:33 ` Miles Bader
2002-07-02 20:09 ` Jon Cast
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 16:26 UTC (permalink / raw
Cc: Stefan Monnier, Eli Zaretskii, storm, Emacs Devel Mailing List
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:26 ` Stefan Monnier
@ 2002-07-02 16:33 ` Miles Bader
2002-07-02 16:38 ` Stefan Monnier
2002-07-02 20:09 ` Jon Cast
1 sibling, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-07-02 16:33 UTC (permalink / raw
Cc: Eli Zaretskii, storm, Emacs Devel Mailing List
"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'
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:33 ` Miles Bader
@ 2002-07-02 16:38 ` Stefan Monnier
2002-07-02 20:12 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 16:38 UTC (permalink / raw
Cc: Stefan Monnier, Eli Zaretskii, storm, Emacs Devel Mailing List
> "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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:09 ` Simon Josefsson
@ 2002-07-02 16:40 ` Eli Zaretskii
2002-07-02 19:17 ` Stefan Monnier
` (2 more replies)
2002-07-02 20:05 ` Jon Cast
1 sibling, 3 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-02 16:40 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:40 ` Eli Zaretskii
@ 2002-07-02 19:17 ` Stefan Monnier
2002-07-02 20:55 ` Kim F. Storm
` (2 more replies)
2002-07-02 21:10 ` Kim F. Storm
2002-07-05 17:51 ` Simon Josefsson
2 siblings, 3 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 19:17 UTC (permalink / raw
Cc: Simon Josefsson, Emacs Devel Mailing List
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 15:09 ` Stefan Monnier
2002-07-02 15:20 ` Miles Bader
@ 2002-07-02 19:41 ` Jon Cast
2002-07-02 19:54 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 19:41 UTC (permalink / raw
Cc: Eli Zaretskii, burton, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 15:28 ` Stefan Monnier
2002-07-02 15:58 ` Miles Bader
@ 2002-07-02 19:52 ` Jon Cast
2002-07-02 20:05 ` Stefan Monnier
2002-07-02 21:30 ` Robert J. Chassell
1 sibling, 2 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 19:52 UTC (permalink / raw
Cc: Eli Zaretskii, storm, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 19:41 ` Jon Cast
@ 2002-07-02 19:54 ` Stefan Monnier
2002-07-02 20:51 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 19:54 UTC (permalink / raw
Cc: Stefan Monnier, Eli Zaretskii, burton, Emacs Devel Mailing List
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:05 ` Stefan Monnier
2002-07-02 16:23 ` Miles Bader
@ 2002-07-02 19:56 ` Jon Cast
1 sibling, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 19:56 UTC (permalink / raw
Cc: Miles Bader, Eli Zaretskii, storm, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:09 ` Simon Josefsson
2002-07-02 16:40 ` Eli Zaretskii
@ 2002-07-02 20:05 ` Jon Cast
1 sibling, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 20:05 UTC (permalink / raw
Cc: Miles Bader, Stefan Monnier, Eli Zaretskii, storm,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 19:52 ` Jon Cast
@ 2002-07-02 20:05 ` Stefan Monnier
2002-07-02 21:03 ` Jon Cast
2002-07-02 21:30 ` Robert J. Chassell
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 20:05 UTC (permalink / raw
Cc: Stefan Monnier, Eli Zaretskii, storm, Emacs Devel Mailing List
> > > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:26 ` Stefan Monnier
2002-07-02 16:33 ` Miles Bader
@ 2002-07-02 20:09 ` Jon Cast
2002-07-02 20:18 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 20:09 UTC (permalink / raw
Cc: Miles Bader, Eli Zaretskii, storm, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:38 ` Stefan Monnier
@ 2002-07-02 20:12 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 20:12 UTC (permalink / raw
Cc: Miles Bader, Eli Zaretskii, storm, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 20:09 ` Jon Cast
@ 2002-07-02 20:18 ` Stefan Monnier
2002-07-02 21:15 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-07-02 20:18 UTC (permalink / raw
Cc: Stefan Monnier, Miles Bader, Eli Zaretskii, storm,
Emacs Devel Mailing List
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-06-30 19:06 ` Simon Josefsson
@ 2002-07-02 20:22 ` Jon Cast
2002-07-03 4:57 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 20:22 UTC (permalink / raw
Cc: Eli Zaretskii, burton, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 8:49 ` Kim F. Storm
2002-07-02 8:06 ` Miles Bader
2002-07-02 10:08 ` Eli Zaretskii
@ 2002-07-02 20:30 ` Jon Cast
2002-07-02 21:42 ` Kim F. Storm
2 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 20:30 UTC (permalink / raw
Cc: Francesco Potorti`, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 9:43 ` Kim F. Storm
2002-07-02 9:50 ` Juanma Barranquero
2002-07-02 10:11 ` Eli Zaretskii
@ 2002-07-02 20:38 ` Jon Cast
2002-07-02 21:46 ` Jason Rumney
2002-07-03 20:57 ` Richard Stallman
3 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 20:38 UTC (permalink / raw
Cc: Miles Bader, Francesco Potorti`, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 9:50 ` Juanma Barranquero
@ 2002-07-02 20:44 ` Jon Cast
2002-07-03 2:44 ` Juanma Barranquero
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 20:44 UTC (permalink / raw
Cc: Kim F. Storm, Miles Bader, Francesco Potorti`, Eli Zaretskii,
burton, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 19:54 ` Stefan Monnier
@ 2002-07-02 20:51 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 20:51 UTC (permalink / raw
Cc: Eli Zaretskii, burton, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 19:17 ` Stefan Monnier
@ 2002-07-02 20:55 ` Kim F. Storm
2002-07-02 21:04 ` Jon Cast
2002-07-03 4:49 ` Eli Zaretskii
2 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-02 20:55 UTC (permalink / raw
Cc: Eli Zaretskii, Simon Josefsson, Emacs Devel Mailing List
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 20:05 ` Stefan Monnier
@ 2002-07-02 21:03 ` Jon Cast
2002-07-03 4:05 ` Ken Raeburn
2002-07-03 9:17 ` Kai Großjohann
0 siblings, 2 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 21:03 UTC (permalink / raw
Cc: Eli Zaretskii, storm, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 19:17 ` Stefan Monnier
2002-07-02 20:55 ` Kim F. Storm
@ 2002-07-02 21:04 ` Jon Cast
2002-07-03 4:49 ` Eli Zaretskii
2 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 21:04 UTC (permalink / raw
Cc: Eli Zaretskii, Simon Josefsson, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:40 ` Eli Zaretskii
2002-07-02 19:17 ` Stefan Monnier
@ 2002-07-02 21:10 ` Kim F. Storm
2002-07-05 17:51 ` Simon Josefsson
2 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-02 21:10 UTC (permalink / raw
Cc: Simon Josefsson, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 20:18 ` Stefan Monnier
@ 2002-07-02 21:15 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 21:15 UTC (permalink / raw
Cc: Miles Bader, Eli Zaretskii, storm, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 21:42 ` Kim F. Storm
@ 2002-07-02 21:22 ` Jon Cast
2002-07-02 22:48 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-02 21:22 UTC (permalink / raw
Cc: Francesco Potorti`, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 19:52 ` Jon Cast
2002-07-02 20:05 ` Stefan Monnier
@ 2002-07-02 21:30 ` Robert J. Chassell
2002-07-03 0:33 ` Jon Cast
1 sibling, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2002-07-02 21:30 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 20:30 ` Jon Cast
@ 2002-07-02 21:42 ` Kim F. Storm
2002-07-02 21:22 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-02 21:42 UTC (permalink / raw
Cc: Francesco Potorti`, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 20:38 ` Jon Cast
@ 2002-07-02 21:46 ` Jason Rumney
2002-07-04 6:08 ` Juanma Barranquero
0 siblings, 1 reply; 1364+ messages in thread
From: Jason Rumney @ 2002-07-02 21:46 UTC (permalink / raw
Cc: Kim F. Storm, Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 21:22 ` Jon Cast
@ 2002-07-02 22:48 ` Kim F. Storm
2002-07-03 0:45 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-02 22:48 UTC (permalink / raw
Cc: Francesco Potorti`, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 21:30 ` Robert J. Chassell
@ 2002-07-03 0:33 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 0:33 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 22:48 ` Kim F. Storm
@ 2002-07-03 0:45 ` Jon Cast
2002-07-03 12:56 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 0:45 UTC (permalink / raw
Cc: Francesco Potorti`, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 2:44 ` Juanma Barranquero
@ 2002-07-03 0:52 ` Jon Cast
2002-07-03 7:58 ` Juanma Barranquero
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 0:52 UTC (permalink / raw
Cc: Kim F. Storm, Miles Bader, Francesco Potorti`, Eli Zaretskii,
burton, Emacs Devel Mailing List
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 20:44 ` Jon Cast
@ 2002-07-03 2:44 ` Juanma Barranquero
2002-07-03 0:52 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Juanma Barranquero @ 2002-07-03 2:44 UTC (permalink / raw
Cc: Kim F. Storm, Miles Bader, Francesco Potorti`, Eli Zaretskii,
burton, Emacs Devel Mailing List
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>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 21:03 ` Jon Cast
@ 2002-07-03 4:05 ` Ken Raeburn
2002-07-03 20:54 ` Jon Cast
2002-07-03 9:17 ` Kai Großjohann
1 sibling, 1 reply; 1364+ messages in thread
From: Ken Raeburn @ 2002-07-03 4:05 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 19:17 ` Stefan Monnier
2002-07-02 20:55 ` Kim F. Storm
2002-07-02 21:04 ` Jon Cast
@ 2002-07-03 4:49 ` Eli Zaretskii
2 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-03 4:49 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 20:22 ` Jon Cast
@ 2002-07-03 4:57 ` Eli Zaretskii
2002-07-03 21:00 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-03 4:57 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 0:52 ` Jon Cast
@ 2002-07-03 7:58 ` Juanma Barranquero
0 siblings, 0 replies; 1364+ messages in thread
From: Juanma Barranquero @ 2002-07-03 7:58 UTC (permalink / raw
Cc: Kim F. Storm, Miles Bader, Francesco Potorti`, Eli Zaretskii,
burton, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 21:03 ` Jon Cast
2002-07-03 4:05 ` Ken Raeburn
@ 2002-07-03 9:17 ` Kai Großjohann
2002-07-03 21:06 ` Jon Cast
1 sibling, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-07-03 9:17 UTC (permalink / raw
Cc: Stefan Monnier, Eli Zaretskii, storm, Emacs Devel Mailing List
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 0:45 ` Jon Cast
@ 2002-07-03 12:56 ` Kim F. Storm
2002-07-03 21:27 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-03 12:56 UTC (permalink / raw
Cc: Francesco Potorti`, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 4:05 ` Ken Raeburn
@ 2002-07-03 20:54 ` Jon Cast
2002-07-04 1:35 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 20:54 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 10:08 ` Eli Zaretskii
2002-07-02 15:28 ` Stefan Monnier
@ 2002-07-03 20:57 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-07-03 20:57 UTC (permalink / raw
Cc: storm, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 9:43 ` Kim F. Storm
` (2 preceding siblings ...)
2002-07-02 20:38 ` Jon Cast
@ 2002-07-03 20:57 ` Richard Stallman
2002-07-03 21:35 ` Jon Cast
3 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-07-03 20:57 UTC (permalink / raw
Cc: miles, pot, jcast, eliz, burton, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 4:57 ` Eli Zaretskii
@ 2002-07-03 21:00 ` Jon Cast
2002-07-04 4:36 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 21:00 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 9:17 ` Kai Großjohann
@ 2002-07-03 21:06 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 21:06 UTC (permalink / raw
Cc: Stefan Monnier, Eli Zaretskii, storm, Emacs Devel Mailing List
[-- 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 12:56 ` Kim F. Storm
@ 2002-07-03 21:27 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 21:27 UTC (permalink / raw
Cc: Francesco Potorti`, Eli Zaretskii, burton,
Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 20:57 ` Richard Stallman
@ 2002-07-03 21:35 ` Jon Cast
2002-07-03 22:03 ` Miles Bader
2002-07-04 22:04 ` Kim F. Storm
0 siblings, 2 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 21:35 UTC (permalink / raw
Cc: storm, miles, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 21:35 ` Jon Cast
@ 2002-07-03 22:03 ` Miles Bader
2002-07-03 23:08 ` Jon Cast
2002-07-04 18:24 ` Richard Stallman
2002-07-04 22:04 ` Kim F. Storm
1 sibling, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2002-07-03 22:03 UTC (permalink / raw
Cc: rms, storm, pot, eliz, burton, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 22:03 ` Miles Bader
@ 2002-07-03 23:08 ` Jon Cast
2002-07-04 18:24 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-03 23:08 UTC (permalink / raw
Cc: rms, storm, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 20:54 ` Jon Cast
@ 2002-07-04 1:35 ` Miles Bader
2002-07-04 1:39 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-07-04 1:35 UTC (permalink / raw
Cc: Ken Raeburn, Emacs Devel Mailing List
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]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 1:35 ` Miles Bader
@ 2002-07-04 1:39 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-04 1:39 UTC (permalink / raw
Cc: Ken Raeburn, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 21:00 ` Jon Cast
@ 2002-07-04 4:36 ` Eli Zaretskii
2002-07-04 16:37 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-04 4:36 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 21:46 ` Jason Rumney
@ 2002-07-04 6:08 ` Juanma Barranquero
0 siblings, 0 replies; 1364+ messages in thread
From: Juanma Barranquero @ 2002-07-04 6:08 UTC (permalink / raw
Cc: Jon Cast, Kim F. Storm, Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 4:36 ` Eli Zaretskii
@ 2002-07-04 16:37 ` Jon Cast
2002-07-05 17:20 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-04 16:37 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 22:03 ` Miles Bader
2002-07-03 23:08 ` Jon Cast
@ 2002-07-04 18:24 ` Richard Stallman
2002-07-04 23:16 ` Jon Cast
2002-07-05 1:20 ` Miles Bader
1 sibling, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-07-04 18:24 UTC (permalink / raw
Cc: jcast, storm, pot, eliz, burton, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-03 21:35 ` Jon Cast
2002-07-03 22:03 ` Miles Bader
@ 2002-07-04 22:04 ` Kim F. Storm
2002-07-04 23:31 ` Jon Cast
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-04 22:04 UTC (permalink / raw
Cc: rms, miles, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 18:24 ` Richard Stallman
@ 2002-07-04 23:16 ` Jon Cast
2002-07-05 22:07 ` Richard Stallman
2002-07-05 1:20 ` Miles Bader
1 sibling, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-04 23:16 UTC (permalink / raw
Cc: miles, storm, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 22:04 ` Kim F. Storm
@ 2002-07-04 23:31 ` Jon Cast
2002-07-05 20:55 ` Kim F. Storm
2002-07-05 22:07 ` Richard Stallman
2002-07-05 12:07 ` Kai Großjohann
2002-07-05 22:07 ` Richard Stallman
2 siblings, 2 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-04 23:31 UTC (permalink / raw
Cc: rms, miles, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 18:24 ` Richard Stallman
2002-07-04 23:16 ` Jon Cast
@ 2002-07-05 1:20 ` Miles Bader
2002-07-05 22:07 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-07-05 1:20 UTC (permalink / raw
Cc: jcast, storm, pot, eliz, burton, emacs-devel
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]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 22:04 ` Kim F. Storm
2002-07-04 23:31 ` Jon Cast
@ 2002-07-05 12:07 ` Kai Großjohann
2002-07-05 13:13 ` Miles Bader
2002-07-05 22:07 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-07-05 12:07 UTC (permalink / raw
Cc: Jon Cast, rms, miles, pot, eliz, burton, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 12:07 ` Kai Großjohann
@ 2002-07-05 13:13 ` Miles Bader
2002-07-05 13:41 ` Kai Großjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-07-05 13:13 UTC (permalink / raw
Cc: Kim F. Storm, Jon Cast, rms, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 13:13 ` Miles Bader
@ 2002-07-05 13:41 ` Kai Großjohann
0 siblings, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2002-07-05 13:41 UTC (permalink / raw
Cc: Kim F. Storm, Jon Cast, rms, pot, eliz, burton, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 16:37 ` Jon Cast
@ 2002-07-05 17:20 ` Eli Zaretskii
2002-07-05 23:02 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-05 17:20 UTC (permalink / raw
Cc: emacs-devel
> 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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-02 16:40 ` Eli Zaretskii
2002-07-02 19:17 ` Stefan Monnier
2002-07-02 21:10 ` Kim F. Storm
@ 2002-07-05 17:51 ` Simon Josefsson
2002-07-05 19:14 ` Eli Zaretskii
2 siblings, 1 reply; 1364+ messages in thread
From: Simon Josefsson @ 2002-07-05 17:51 UTC (permalink / raw
Cc: Emacs Devel Mailing List
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. ;-)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 17:51 ` Simon Josefsson
@ 2002-07-05 19:14 ` Eli Zaretskii
0 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-05 19:14 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 23:31 ` Jon Cast
@ 2002-07-05 20:55 ` Kim F. Storm
2002-07-05 23:07 ` Jon Cast
2002-07-05 22:07 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-07-05 20:55 UTC (permalink / raw
Cc: rms, miles, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 22:04 ` Kim F. Storm
2002-07-04 23:31 ` Jon Cast
2002-07-05 12:07 ` Kai Großjohann
@ 2002-07-05 22:07 ` Richard Stallman
2002-07-09 2:19 ` Jon Cast
2 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-07-05 22:07 UTC (permalink / raw
Cc: jcast, miles, pot, eliz, burton, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 23:16 ` Jon Cast
@ 2002-07-05 22:07 ` Richard Stallman
2002-07-05 23:09 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-07-05 22:07 UTC (permalink / raw
Cc: miles, storm, pot, eliz, burton, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-04 23:31 ` Jon Cast
2002-07-05 20:55 ` Kim F. Storm
@ 2002-07-05 22:07 ` Richard Stallman
2002-07-05 23:11 ` Jon Cast
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-07-05 22:07 UTC (permalink / raw
Cc: storm, miles, pot, eliz, burton, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 1:20 ` Miles Bader
@ 2002-07-05 22:07 ` Richard Stallman
2002-07-05 23:14 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-07-05 22:07 UTC (permalink / raw
Cc: jcast, storm, pot, eliz, burton, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 17:20 ` Eli Zaretskii
@ 2002-07-05 23:02 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-05 23:02 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 20:55 ` Kim F. Storm
@ 2002-07-05 23:07 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-05 23:07 UTC (permalink / raw
Cc: rms, miles, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 22:07 ` Richard Stallman
@ 2002-07-05 23:09 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-05 23:09 UTC (permalink / raw
Cc: miles, storm, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 22:07 ` Richard Stallman
@ 2002-07-05 23:11 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-05 23:11 UTC (permalink / raw
Cc: storm, miles, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 22:07 ` Richard Stallman
@ 2002-07-05 23:14 ` Jon Cast
2002-07-05 23:23 ` Francesco Potorti`
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-05 23:14 UTC (permalink / raw
Cc: miles, storm, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 23:14 ` Jon Cast
@ 2002-07-05 23:23 ` Francesco Potorti`
2002-07-06 23:31 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Francesco Potorti` @ 2002-07-05 23:23 UTC (permalink / raw
Cc: emacs-devel, burton, eliz, storm, miles, rms
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 23:23 ` Francesco Potorti`
@ 2002-07-06 23:31 ` Richard Stallman
2002-07-09 3:22 ` Jon Cast
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-07-06 23:31 UTC (permalink / raw
Cc: jcast, emacs-devel, burton, eliz, storm, miles
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-05 22:07 ` Richard Stallman
@ 2002-07-09 2:19 ` Jon Cast
2002-07-09 5:43 ` Eli Zaretskii
2002-07-09 18:51 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-09 2:19 UTC (permalink / raw
Cc: storm, miles, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-06 23:31 ` Richard Stallman
@ 2002-07-09 3:22 ` Jon Cast
2002-07-09 18:51 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Jon Cast @ 2002-07-09 3:22 UTC (permalink / raw
Cc: pot, emacs-devel, burton, eliz, storm, miles
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-09 2:19 ` Jon Cast
@ 2002-07-09 5:43 ` Eli Zaretskii
2002-07-09 18:51 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-07-09 5:43 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-09 2:19 ` Jon Cast
2002-07-09 5:43 ` Eli Zaretskii
@ 2002-07-09 18:51 ` Richard Stallman
2002-07-10 18:24 ` Jon Cast
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-07-09 18:51 UTC (permalink / raw
Cc: storm, miles, pot, eliz, burton, emacs-devel
> 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".
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-09 3:22 ` Jon Cast
@ 2002-07-09 18:51 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-07-09 18:51 UTC (permalink / raw
Cc: pot, emacs-devel, burton, eliz, storm, miles
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: No calc in pretest?
2002-07-09 18:51 ` Richard Stallman
@ 2002-07-10 18:24 ` Jon Cast
0 siblings, 0 replies; 1364+ messages in thread
From: Jon Cast @ 2002-07-10 18:24 UTC (permalink / raw
Cc: storm, miles, pot, eliz, burton, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* crash in display, triggered by calendar
@ 2002-08-06 13:15 ` Sam Steingold
2002-08-06 13:38 ` Ed Reingold
0 siblings, 1 reply; 1364+ messages in thread
From: Sam Steingold @ 2002-08-06 13:15 UTC (permalink / raw
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: crash in display, triggered by calendar
2002-08-06 13:15 ` crash in display, triggered by calendar Sam Steingold
@ 2002-08-06 13:38 ` Ed Reingold
2002-08-06 14:05 ` Sam Steingold
0 siblings, 1 reply; 1364+ messages in thread
From: Ed Reingold @ 2002-08-06 13:38 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: crash in display, triggered by calendar
2002-08-06 13:38 ` Ed Reingold
@ 2002-08-06 14:05 ` Sam Steingold
2002-08-06 14:38 ` Alan Shutko
2002-08-07 14:23 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Sam Steingold @ 2002-08-06 14:05 UTC (permalink / raw
Cc: emacs-devel
> * 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: crash in display, triggered by calendar
2002-08-06 14:05 ` Sam Steingold
@ 2002-08-06 14:38 ` Alan Shutko
2002-08-06 14:51 ` Ed Reingold
2002-08-07 14:23 ` Richard Stallman
2002-08-07 14:23 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Alan Shutko @ 2002-08-06 14:38 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: crash in display, triggered by calendar
2002-08-06 14:38 ` Alan Shutko
@ 2002-08-06 14:51 ` Ed Reingold
2002-08-06 15:00 ` Sam Steingold
2002-08-07 14:23 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Ed Reingold @ 2002-08-06 14:51 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: crash in display, triggered by calendar
2002-08-06 14:51 ` Ed Reingold
@ 2002-08-06 15:00 ` Sam Steingold
0 siblings, 0 replies; 1364+ messages in thread
From: Sam Steingold @ 2002-08-06 15:00 UTC (permalink / raw
Cc: Alan Shutko, emacs-devel
> * 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: crash in display, triggered by calendar
2002-08-06 14:05 ` Sam Steingold
2002-08-06 14:38 ` Alan Shutko
@ 2002-08-07 14:23 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-08-07 14:23 UTC (permalink / raw
Cc: reingold, emacs-devel
I suggest that you remove it.
RMS reads this list - I hope he will withdraw his insistence.
Nope.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: crash in display, triggered by calendar
2002-08-06 14:38 ` Alan Shutko
2002-08-06 14:51 ` Ed Reingold
@ 2002-08-07 14:23 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-08-07 14:23 UTC (permalink / raw
Cc: reingold, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-20 15:32 Suggestions for mode-line-format changes Kim F. Storm
@ 2002-08-20 14:51 ` Romain FRANCOISE
2002-08-21 0:11 ` Richard Stallman
` (3 subsequent siblings)
4 siblings, 0 replies; 1364+ messages in thread
From: Romain FRANCOISE @ 2002-08-20 14:51 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Suggestions for mode-line-format changes
@ 2002-08-20 15:32 Kim F. Storm
2002-08-20 14:51 ` Romain FRANCOISE
` (4 more replies)
0 siblings, 5 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-20 15:32 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-20 15:32 Suggestions for mode-line-format changes Kim F. Storm
2002-08-20 14:51 ` Romain FRANCOISE
@ 2002-08-21 0:11 ` Richard Stallman
2002-08-21 13:11 ` Kim F. Storm
2002-08-21 0:25 ` Kim F. Storm
` (2 subsequent siblings)
4 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-08-21 0:11 UTC (permalink / raw
Cc: emacs-devel
Your ideas sound good--would you please go ahead and implement them?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-20 15:32 Suggestions for mode-line-format changes Kim F. Storm
2002-08-20 14:51 ` Romain FRANCOISE
2002-08-21 0:11 ` Richard Stallman
@ 2002-08-21 0:25 ` Kim F. Storm
2002-08-21 4:29 ` Kenichi Handa
2002-08-23 16:33 ` Alan Shutko
4 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-21 0:25 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-20 15:32 Suggestions for mode-line-format changes Kim F. Storm
` (2 preceding siblings ...)
2002-08-21 0:25 ` Kim F. Storm
@ 2002-08-21 4:29 ` Kenichi Handa
2002-08-21 4:52 ` Miles Bader
` (2 more replies)
2002-08-23 16:33 ` Alan Shutko
4 siblings, 3 replies; 1364+ messages in thread
From: Kenichi Handa @ 2002-08-21 4:29 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 4:29 ` Kenichi Handa
@ 2002-08-21 4:52 ` Miles Bader
2002-08-21 9:33 ` Kim F. Storm
2002-08-21 9:29 ` Kim F. Storm
2002-08-23 16:35 ` Alan Shutko
2 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-08-21 4:52 UTC (permalink / raw
Cc: storm, emacs-devel
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_)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 4:29 ` Kenichi Handa
2002-08-21 4:52 ` Miles Bader
@ 2002-08-21 9:29 ` Kim F. Storm
2002-08-23 16:35 ` Alan Shutko
2 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-21 9:29 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 4:52 ` Miles Bader
@ 2002-08-21 9:33 ` Kim F. Storm
2002-08-21 11:01 ` Miles Bader
2002-08-23 16:38 ` Alan Shutko
0 siblings, 2 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-21 9:33 UTC (permalink / raw
Cc: Kenichi Handa, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 9:33 ` Kim F. Storm
@ 2002-08-21 11:01 ` Miles Bader
2002-08-21 11:09 ` Kenichi Handa
[not found] ` <m2vg63ekjg.fsf@primate.xs4all.nl>
2002-08-23 16:38 ` Alan Shutko
1 sibling, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2002-08-21 11:01 UTC (permalink / raw
Cc: Kenichi Handa, emacs-devel
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 11:01 ` Miles Bader
@ 2002-08-21 11:09 ` Kenichi Handa
[not found] ` <m2vg63ekjg.fsf@primate.xs4all.nl>
1 sibling, 0 replies; 1364+ messages in thread
From: Kenichi Handa @ 2002-08-21 11:09 UTC (permalink / raw
Cc: storm, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 0:11 ` Richard Stallman
@ 2002-08-21 13:11 ` Kim F. Storm
2002-08-22 3:44 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-21 13:11 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
[not found] ` <m2vg63ekjg.fsf@primate.xs4all.nl>
@ 2002-08-22 2:38 ` Miles Bader
2002-08-23 0:11 ` ediff user interface (Re: Suggestions for mode-line-format changes) Karl Eichwalder
2002-08-24 2:33 ` Suggestions for mode-line-format changes Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2002-08-22 2:38 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 13:11 ` Kim F. Storm
@ 2002-08-22 3:44 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-08-22 3:44 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* ediff user interface (Re: Suggestions for mode-line-format changes)
2002-08-22 2:38 ` Miles Bader
@ 2002-08-23 0:11 ` Karl Eichwalder
2002-08-23 8:28 ` Andreas Schwab
2002-08-24 2:33 ` Suggestions for mode-line-format changes Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Karl Eichwalder @ 2002-08-23 0:11 UTC (permalink / raw
Cc: emacs-devel
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/ | (*)/'(*)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: ediff user interface (Re: Suggestions for mode-line-format changes)
2002-08-23 0:11 ` ediff user interface (Re: Suggestions for mode-line-format changes) Karl Eichwalder
@ 2002-08-23 8:28 ` Andreas Schwab
0 siblings, 0 replies; 1364+ messages in thread
From: Andreas Schwab @ 2002-08-23 8:28 UTC (permalink / raw
Cc: Miles Bader, emacs-devel
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-20 15:32 Suggestions for mode-line-format changes Kim F. Storm
` (3 preceding siblings ...)
2002-08-21 4:29 ` Kenichi Handa
@ 2002-08-23 16:33 ` Alan Shutko
2002-08-23 16:58 ` Bill White
` (2 more replies)
4 siblings, 3 replies; 1364+ messages in thread
From: Alan Shutko @ 2002-08-23 16:33 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 4:29 ` Kenichi Handa
2002-08-21 4:52 ` Miles Bader
2002-08-21 9:29 ` Kim F. Storm
@ 2002-08-23 16:35 ` Alan Shutko
2002-08-24 0:42 ` Kenichi Handa
2 siblings, 1 reply; 1364+ messages in thread
From: Alan Shutko @ 2002-08-23 16:35 UTC (permalink / raw
Cc: storm, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-21 9:33 ` Kim F. Storm
2002-08-21 11:01 ` Miles Bader
@ 2002-08-23 16:38 ` Alan Shutko
[not found] ` <m2hehasikt.fsf@primate.xs4all.nl>
1 sibling, 1 reply; 1364+ messages in thread
From: Alan Shutko @ 2002-08-23 16:38 UTC (permalink / raw
Cc: Miles Bader, Kenichi Handa, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-23 16:33 ` Alan Shutko
@ 2002-08-23 16:58 ` Bill White
2002-08-25 23:41 ` Kim F. Storm
2002-08-23 17:08 ` Kai Großjohann
2002-08-25 5:26 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Bill White @ 2002-08-23 16:58 UTC (permalink / raw
Cc: Kim F. Storm, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-23 16:33 ` Alan Shutko
2002-08-23 16:58 ` Bill White
@ 2002-08-23 17:08 ` Kai Großjohann
2002-08-25 5:26 ` Richard Stallman
2002-08-25 5:26 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Kai Großjohann @ 2002-08-23 17:08 UTC (permalink / raw
Cc: Kim F. Storm, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-23 16:35 ` Alan Shutko
@ 2002-08-24 0:42 ` Kenichi Handa
2002-08-25 18:23 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Kenichi Handa @ 2002-08-24 0:42 UTC (permalink / raw
Cc: storm, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-22 2:38 ` Miles Bader
2002-08-23 0:11 ` ediff user interface (Re: Suggestions for mode-line-format changes) Karl Eichwalder
@ 2002-08-24 2:33 ` Richard Stallman
2002-08-25 23:36 ` Kim F. Storm
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-08-24 2:33 UTC (permalink / raw
Cc: emacs-devel, kifer
[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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-23 16:33 ` Alan Shutko
2002-08-23 16:58 ` Bill White
2002-08-23 17:08 ` Kai Großjohann
@ 2002-08-25 5:26 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-08-25 5:26 UTC (permalink / raw
Cc: storm, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-23 17:08 ` Kai Großjohann
@ 2002-08-25 5:26 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-08-25 5:26 UTC (permalink / raw
Cc: ats, storm, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-24 0:42 ` Kenichi Handa
@ 2002-08-25 18:23 ` Stefan Monnier
2002-08-26 7:01 ` Kenichi Handa
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-08-25 18:23 UTC (permalink / raw
Cc: ats, storm, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-25 23:36 ` Kim F. Storm
@ 2002-08-25 22:52 ` Miles Bader
2002-08-26 21:16 ` Michael Kifer
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-08-25 22:52 UTC (permalink / raw
Cc: rms, emacs-devel, kifer
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-25 23:41 ` Kim F. Storm
@ 2002-08-25 23:12 ` Alan Shutko
2002-08-26 4:42 ` Eli Zaretskii
2002-08-26 10:20 ` Kim F. Storm
2002-08-26 10:25 ` Mario Lang
1 sibling, 2 replies; 1364+ messages in thread
From: Alan Shutko @ 2002-08-25 23:12 UTC (permalink / raw
Cc: Bill White, emacs-devel
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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-24 2:33 ` Suggestions for mode-line-format changes Richard Stallman
@ 2002-08-25 23:36 ` Kim F. Storm
2002-08-25 22:52 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-25 23:36 UTC (permalink / raw
Cc: miles, emacs-devel, kifer
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-23 16:58 ` Bill White
@ 2002-08-25 23:41 ` Kim F. Storm
2002-08-25 23:12 ` Alan Shutko
2002-08-26 10:25 ` Mario Lang
0 siblings, 2 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-25 23:41 UTC (permalink / raw
Cc: Alan Shutko, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-25 23:12 ` Alan Shutko
@ 2002-08-26 4:42 ` Eli Zaretskii
2002-08-26 7:12 ` Miles Bader
[not found] ` <m265xqsfse.fsf@primate.xs4all.nl>
2002-08-26 10:20 ` Kim F. Storm
1 sibling, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2002-08-26 4:42 UTC (permalink / raw
Cc: Bill White, emacs-devel
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.)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-25 18:23 ` Stefan Monnier
@ 2002-08-26 7:01 ` Kenichi Handa
2002-08-26 16:05 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Kenichi Handa @ 2002-08-26 7:01 UTC (permalink / raw
Cc: ats, storm, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-26 4:42 ` Eli Zaretskii
@ 2002-08-26 7:12 ` Miles Bader
[not found] ` <m265xqsfse.fsf@primate.xs4all.nl>
1 sibling, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-08-26 7:12 UTC (permalink / raw
Cc: Alan Shutko, Bill White, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-25 23:12 ` Alan Shutko
2002-08-26 4:42 ` Eli Zaretskii
@ 2002-08-26 10:20 ` Kim F. Storm
2002-08-26 15:51 ` Alan Shutko
2002-08-26 21:51 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-26 10:20 UTC (permalink / raw
Cc: Bill White, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-25 23:41 ` Kim F. Storm
2002-08-25 23:12 ` Alan Shutko
@ 2002-08-26 10:25 ` Mario Lang
2002-08-26 15:01 ` Kim F. Storm
2002-08-26 21:51 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Mario Lang @ 2002-08-26 10:25 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-26 10:25 ` Mario Lang
@ 2002-08-26 15:01 ` Kim F. Storm
2002-08-26 21:51 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-26 15:01 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-26 10:20 ` Kim F. Storm
@ 2002-08-26 15:51 ` Alan Shutko
2002-08-26 21:51 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Alan Shutko @ 2002-08-26 15:51 UTC (permalink / raw
Cc: Bill White, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-26 7:01 ` Kenichi Handa
@ 2002-08-26 16:05 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-08-26 16:05 UTC (permalink / raw
Cc: monnier+gnu/emacs, ats, storm, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-25 22:52 ` Miles Bader
@ 2002-08-26 21:16 ` Michael Kifer
2002-08-27 1:52 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Michael Kifer @ 2002-08-26 21:16 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-26 10:20 ` Kim F. Storm
2002-08-26 15:51 ` Alan Shutko
@ 2002-08-26 21:51 ` Richard Stallman
2002-08-27 9:20 ` Kim F. Storm
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-08-26 21:51 UTC (permalink / raw
Cc: ats, billw, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-26 10:25 ` Mario Lang
2002-08-26 15:01 ` Kim F. Storm
@ 2002-08-26 21:51 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-08-26 21:51 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-26 21:16 ` Michael Kifer
@ 2002-08-27 1:52 ` Miles Bader
2002-08-27 2:28 ` Michael Kifer
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-08-27 1:52 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 1:52 ` Miles Bader
@ 2002-08-27 2:28 ` Michael Kifer
2002-08-27 2:53 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Michael Kifer @ 2002-08-27 2:28 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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]
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 2:28 ` Michael Kifer
@ 2002-08-27 2:53 ` Miles Bader
2002-08-27 3:38 ` Michael Kifer
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-08-27 2:53 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 2:53 ` Miles Bader
@ 2002-08-27 3:38 ` Michael Kifer
2002-08-27 4:10 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Michael Kifer @ 2002-08-27 3:38 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 3:38 ` Michael Kifer
@ 2002-08-27 4:10 ` Miles Bader
2002-08-27 4:33 ` Michael Kifer
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-08-27 4:10 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 4:10 ` Miles Bader
@ 2002-08-27 4:33 ` Michael Kifer
2002-08-27 4:56 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Michael Kifer @ 2002-08-27 4:33 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
>>>>> "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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 4:33 ` Michael Kifer
@ 2002-08-27 4:56 ` Miles Bader
2002-08-27 5:18 ` Michael Kifer
2002-08-27 9:16 ` Kim F. Storm
0 siblings, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2002-08-27 4:56 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 4:56 ` Miles Bader
@ 2002-08-27 5:18 ` Michael Kifer
2002-08-27 5:37 ` Miles Bader
2002-08-27 9:16 ` Kim F. Storm
1 sibling, 1 reply; 1364+ messages in thread
From: Michael Kifer @ 2002-08-27 5:18 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 5:18 ` Michael Kifer
@ 2002-08-27 5:37 ` Miles Bader
2002-08-27 5:51 ` Michael Kifer
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-08-27 5:37 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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_)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 5:37 ` Miles Bader
@ 2002-08-27 5:51 ` Michael Kifer
2002-08-27 6:25 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Michael Kifer @ 2002-08-27 5:51 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 5:51 ` Michael Kifer
@ 2002-08-27 6:25 ` Miles Bader
2002-08-27 9:16 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-08-27 6:25 UTC (permalink / raw
Cc: Kim F. Storm, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 9:20 ` Kim F. Storm
@ 2002-08-27 8:26 ` Miles Bader
2002-08-27 10:34 ` Kim F. Storm
2002-08-28 6:52 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-08-27 8:26 UTC (permalink / raw
Cc: rms, ats, billw, emacs-devel
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"
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 4:56 ` Miles Bader
2002-08-27 5:18 ` Michael Kifer
@ 2002-08-27 9:16 ` Kim F. Storm
1 sibling, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-27 9:16 UTC (permalink / raw
Cc: Michael Kifer, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 6:25 ` Miles Bader
@ 2002-08-27 9:16 ` Kim F. Storm
0 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-27 9:16 UTC (permalink / raw
Cc: Michael Kifer, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-26 21:51 ` Richard Stallman
@ 2002-08-27 9:20 ` Kim F. Storm
2002-08-27 8:26 ` Miles Bader
2002-08-28 6:52 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-27 9:20 UTC (permalink / raw
Cc: ats, billw, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 8:26 ` Miles Bader
@ 2002-08-27 10:34 ` Kim F. Storm
0 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-08-27 10:34 UTC (permalink / raw
Cc: rms, ats, billw, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-08-27 9:20 ` Kim F. Storm
2002-08-27 8:26 ` Miles Bader
@ 2002-08-28 6:52 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-08-28 6:52 UTC (permalink / raw
Cc: ats, billw, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
[not found] ` <m2hehasikt.fsf@primate.xs4all.nl>
@ 2002-09-01 0:07 ` Alan Shutko
2002-09-01 0:32 ` Glenn Morris
1 sibling, 0 replies; 1364+ messages in thread
From: Alan Shutko @ 2002-09-01 0:07 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
[not found] ` <m2hehasikt.fsf@primate.xs4all.nl>
2002-09-01 0:07 ` Alan Shutko
@ 2002-09-01 0:32 ` Glenn Morris
1 sibling, 0 replies; 1364+ messages in thread
From: Glenn Morris @ 2002-09-01 0:32 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
[not found] ` <m265xqsfse.fsf@primate.xs4all.nl>
@ 2002-09-02 1:10 ` Miles Bader
2002-09-02 2:38 ` Alan Shutko
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-09-02 1:10 UTC (permalink / raw
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-09-02 1:10 ` Miles Bader
@ 2002-09-02 2:38 ` Alan Shutko
2002-09-02 10:18 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Alan Shutko @ 2002-09-02 2:38 UTC (permalink / raw
Cc: emacs-devel
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 !
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Suggestions for mode-line-format changes
2002-09-02 2:38 ` Alan Shutko
@ 2002-09-02 10:18 ` Kim F. Storm
0 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-09-02 10:18 UTC (permalink / raw
Cc: Miles Bader, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* mh-e 6.2 imminent
@ 2002-10-21 7:26 Bill Wohler
2002-10-21 10:04 ` Kim F. Storm
2002-10-22 3:13 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Bill Wohler @ 2002-10-21 7:26 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-21 10:04 ` Kim F. Storm
@ 2002-10-21 9:37 ` Juanma Barranquero
0 siblings, 0 replies; 1364+ messages in thread
From: Juanma Barranquero @ 2002-10-21 9:37 UTC (permalink / raw
Cc: Bill Wohler, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-21 7:26 mh-e 6.2 imminent Bill Wohler
@ 2002-10-21 10:04 ` Kim F. Storm
2002-10-21 9:37 ` Juanma Barranquero
2002-10-22 3:13 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-10-21 10:04 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-21 7:26 mh-e 6.2 imminent Bill Wohler
2002-10-21 10:04 ` Kim F. Storm
@ 2002-10-22 3:13 ` Richard Stallman
2002-10-23 19:48 ` Bill Wohler
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-10-22 3:13 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-22 3:13 ` Richard Stallman
@ 2002-10-23 19:48 ` Bill Wohler
2002-10-24 7:25 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Bill Wohler @ 2002-10-23 19:48 UTC (permalink / raw
Cc: mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-23 19:48 ` Bill Wohler
@ 2002-10-24 7:25 ` Stefan Monnier
2002-10-24 8:21 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-10-24 7:25 UTC (permalink / raw
Cc: emacs-devel, mh-e-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-24 7:25 ` Stefan Monnier
@ 2002-10-24 8:21 ` Miles Bader
[not found] ` <miles@lsi.nec.co.jp>
` (3 more replies)
0 siblings, 4 replies; 1364+ messages in thread
From: Miles Bader @ 2002-10-24 8:21 UTC (permalink / raw
Cc: Bill Wohler, emacs-devel, mh-e-devel
"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'
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
[not found] ` <miles@lsi.nec.co.jp>
@ 2002-10-24 9:13 ` Mark D. Baushke
2002-10-24 9:24 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Mark D. Baushke @ 2002-10-24 9:13 UTC (permalink / raw
Cc: Stefan Monnier, Bill Wohler, emacs-devel, mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-24 9:13 ` Mark D. Baushke
@ 2002-10-24 9:24 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-10-24 9:24 UTC (permalink / raw
Cc: Stefan Monnier, Bill Wohler, emacs-devel, mh-e-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* checkdoc (was: mh-e 6.2 imminent)
2002-10-24 8:21 ` Miles Bader
[not found] ` <miles@lsi.nec.co.jp>
@ 2002-10-24 9:28 ` Stefan Monnier
2002-10-24 11:13 ` Kim F. Storm
2002-10-25 5:35 ` mh-e 6.2 imminent Richard Stallman
2002-10-29 17:30 ` Francesco Potorti`
3 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2002-10-24 9:28 UTC (permalink / raw
Cc: Stefan Monnier, Bill Wohler, emacs-devel, mh-e-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-24 9:28 ` checkdoc (was: mh-e 6.2 imminent) Stefan Monnier
@ 2002-10-24 11:13 ` Kim F. Storm
2002-10-24 14:45 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-10-24 11:13 UTC (permalink / raw
Cc: Miles Bader, Bill Wohler, emacs-devel, mh-e-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-24 11:13 ` Kim F. Storm
@ 2002-10-24 14:45 ` Miles Bader
2002-10-24 16:15 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-10-24 14:45 UTC (permalink / raw
Cc: Stefan Monnier, Miles Bader, Bill Wohler, emacs-devel, mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-24 14:45 ` Miles Bader
@ 2002-10-24 16:15 ` Kim F. Storm
2002-10-24 23:30 ` Miles Bader
2002-10-25 5:35 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-10-24 16:15 UTC (permalink / raw
Cc: Stefan Monnier, Miles Bader, Bill Wohler, emacs-devel, mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-24 16:15 ` Kim F. Storm
@ 2002-10-24 23:30 ` Miles Bader
2002-10-25 5:35 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-10-24 23:30 UTC (permalink / raw
Cc: Stefan Monnier, Miles Bader, Bill Wohler, emacs-devel, mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-24 8:21 ` Miles Bader
[not found] ` <miles@lsi.nec.co.jp>
2002-10-24 9:28 ` checkdoc (was: mh-e 6.2 imminent) Stefan Monnier
@ 2002-10-25 5:35 ` Richard Stallman
2002-10-25 5:50 ` Miles Bader
2002-10-29 17:30 ` Francesco Potorti`
3 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-10-25 5:35 UTC (permalink / raw
Cc: monnier+gnu/emacs, wohler, emacs-devel, mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-24 16:15 ` Kim F. Storm
2002-10-24 23:30 ` Miles Bader
@ 2002-10-25 5:35 ` Richard Stallman
2002-10-25 9:23 ` Kim F. Storm
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-10-25 5:35 UTC (permalink / raw
Cc: miles, monnier+gnu/emacs, miles, wohler, emacs-devel, mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-25 5:35 ` mh-e 6.2 imminent Richard Stallman
@ 2002-10-25 5:50 ` Miles Bader
2002-10-26 20:15 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-10-25 5:50 UTC (permalink / raw
Cc: monnier+gnu/emacs, wohler, emacs-devel, mh-e-devel
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-25 5:35 ` Richard Stallman
@ 2002-10-25 9:23 ` Kim F. Storm
2002-10-26 20:15 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-10-25 9:23 UTC (permalink / raw
Cc: miles, monnier+gnu/emacs, miles, wohler, emacs-devel, mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-25 5:50 ` Miles Bader
@ 2002-10-26 20:15 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-10-26 20:15 UTC (permalink / raw
Cc: monnier+gnu/emacs, wohler, emacs-devel, mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-25 9:23 ` Kim F. Storm
@ 2002-10-26 20:15 ` Richard Stallman
2002-10-26 23:03 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-10-26 20:15 UTC (permalink / raw
Cc: miles, monnier+gnu/emacs, miles, wohler, emacs-devel, mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-26 20:15 ` Richard Stallman
@ 2002-10-26 23:03 ` Kim F. Storm
2002-10-28 19:19 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-10-26 23:03 UTC (permalink / raw
Cc: miles, monnier+gnu/emacs, miles, wohler, emacs-devel, mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-26 23:03 ` Kim F. Storm
@ 2002-10-28 19:19 ` Richard Stallman
2002-10-28 19:38 ` Henrik Enberg
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2002-10-28 19:19 UTC (permalink / raw
Cc: miles, monnier+gnu/emacs, miles, wohler, emacs-devel, mh-e-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 19:19 ` Richard Stallman
@ 2002-10-28 19:38 ` Henrik Enberg
2002-10-28 21:37 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Henrik Enberg @ 2002-10-28 19:38 UTC (permalink / raw
Cc: storm, miles, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 19:38 ` Henrik Enberg
@ 2002-10-28 21:37 ` Miles Bader
2002-10-28 23:19 ` Kim F. Storm
` (2 more replies)
2002-10-28 21:53 ` Kim F. Storm
2002-10-29 11:28 ` Richard Stallman
2 siblings, 3 replies; 1364+ messages in thread
From: Miles Bader @ 2002-10-28 21:37 UTC (permalink / raw
Cc: rms, storm, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 19:38 ` Henrik Enberg
2002-10-28 21:37 ` Miles Bader
@ 2002-10-28 21:53 ` Kim F. Storm
2002-10-29 1:20 ` Miles Bader
2002-10-29 11:29 ` Richard Stallman
2002-10-29 11:28 ` Richard Stallman
2 siblings, 2 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-10-28 21:53 UTC (permalink / raw
Cc: rms, miles, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 21:37 ` Miles Bader
@ 2002-10-28 23:19 ` Kim F. Storm
2002-10-28 23:22 ` Miles Bader
2002-10-29 11:07 ` Henrik Enberg
2002-10-29 14:31 ` Stefan Monnier
2 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2002-10-28 23:19 UTC (permalink / raw
Cc: Henrik Enberg, rms, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 23:19 ` Kim F. Storm
@ 2002-10-28 23:22 ` Miles Bader
2002-10-29 0:46 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2002-10-28 23:22 UTC (permalink / raw
Cc: Henrik Enberg, rms, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 23:22 ` Miles Bader
@ 2002-10-29 0:46 ` Kim F. Storm
0 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2002-10-29 0:46 UTC (permalink / raw
Cc: Henrik Enberg, rms, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 21:53 ` Kim F. Storm
@ 2002-10-29 1:20 ` Miles Bader
2002-10-29 11:29 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-10-29 1:20 UTC (permalink / raw
Cc: Henrik Enberg, rms, monnier+gnu/emacs, wohler, emacs-devel,
mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 21:37 ` Miles Bader
2002-10-28 23:19 ` Kim F. Storm
@ 2002-10-29 11:07 ` Henrik Enberg
2002-10-29 14:31 ` Stefan Monnier
2 siblings, 0 replies; 1364+ messages in thread
From: Henrik Enberg @ 2002-10-29 11:07 UTC (permalink / raw
Cc: rms, storm, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 19:38 ` Henrik Enberg
2002-10-28 21:37 ` Miles Bader
2002-10-28 21:53 ` Kim F. Storm
@ 2002-10-29 11:28 ` Richard Stallman
2002-10-29 12:55 ` Miles Bader
2002-11-02 0:58 ` Henrik Enberg
2 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-10-29 11:28 UTC (permalink / raw
Cc: storm, miles, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 21:53 ` Kim F. Storm
2002-10-29 1:20 ` Miles Bader
@ 2002-10-29 11:29 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-10-29 11:29 UTC (permalink / raw
Cc: henrik, miles, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-29 11:28 ` Richard Stallman
@ 2002-10-29 12:55 ` Miles Bader
2002-11-02 0:58 ` Henrik Enberg
1 sibling, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-10-29 12:55 UTC (permalink / raw
Cc: henrik, storm, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-28 21:37 ` Miles Bader
2002-10-28 23:19 ` Kim F. Storm
2002-10-29 11:07 ` Henrik Enberg
@ 2002-10-29 14:31 ` Stefan Monnier
2 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2002-10-29 14:31 UTC (permalink / raw
Cc: Henrik Enberg, rms, storm, monnier+gnu/emacs, miles, wohler,
emacs-devel, mh-e-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-24 8:21 ` Miles Bader
` (2 preceding siblings ...)
2002-10-25 5:35 ` mh-e 6.2 imminent Richard Stallman
@ 2002-10-29 17:30 ` Francesco Potorti`
2002-10-30 2:22 ` Miles Bader
[not found] ` <pot@gnu.org>
3 siblings, 2 replies; 1364+ messages in thread
From: Francesco Potorti` @ 2002-10-29 17:30 UTC (permalink / raw
Cc: Stefan Monnier, Bill Wohler, emacs-devel, mh-e-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
[not found] ` <pot@gnu.org>
@ 2002-10-29 17:38 ` Peter S Galbraith
2002-10-30 17:18 ` Richard Stallman
2002-11-02 12:07 ` Francesco Potorti`
2003-01-07 12:40 ` etags -f /dev/stdout enhancement request Francesco Potorti`
1 sibling, 2 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2002-10-29 17:38 UTC (permalink / raw
[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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-29 17:30 ` Francesco Potorti`
@ 2002-10-30 2:22 ` Miles Bader
[not found] ` <pot@gnu.org>
1 sibling, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-10-30 2:22 UTC (permalink / raw
Cc: Stefan Monnier, Bill Wohler, emacs-devel, mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-29 17:38 ` Peter S Galbraith
@ 2002-10-30 17:18 ` Richard Stallman
2002-11-02 12:07 ` Francesco Potorti`
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2002-10-30 17:18 UTC (permalink / raw
Cc: emacs-devel, mh-e-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-10-29 11:28 ` Richard Stallman
2002-10-29 12:55 ` Miles Bader
@ 2002-11-02 0:58 ` Henrik Enberg
2002-11-05 4:26 ` Miles Bader
1 sibling, 1 reply; 1364+ messages in thread
From: Henrik Enberg @ 2002-11-02 0:58 UTC (permalink / raw
Cc: storm, miles, monnier+gnu/emacs, miles, wohler, emacs-devel,
mh-e-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: mh-e 6.2 imminent
2002-10-29 17:38 ` Peter S Galbraith
2002-10-30 17:18 ` Richard Stallman
@ 2002-11-02 12:07 ` Francesco Potorti`
1 sibling, 0 replies; 1364+ messages in thread
From: Francesco Potorti` @ 2002-11-02 12:07 UTC (permalink / raw
Cc: emacs-devel, mh-e-devel
>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 :-)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: checkdoc (was: mh-e 6.2 imminent)
2002-11-02 0:58 ` Henrik Enberg
@ 2002-11-05 4:26 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2002-11-05 4:26 UTC (permalink / raw
Cc: rms, storm, monnier+gnu/emacs, wohler, emacs-devel, mh-e-devel
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"
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Emacs crash in X
[not found] <E18UXkO-00014i-00@troodon.localdomain>
@ 2003-01-04 23:44 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-01-04 23:44 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Emacs crash in X
[not found] ` <rms@gnu.org>
2002-04-20 22:04 ` Nick
@ 2003-01-05 8:12 ` Satyaki Das
2003-01-06 3:26 ` Richard Stallman
2003-01-06 9:07 ` Satyaki Das
` (2 subsequent siblings)
4 siblings, 1 reply; 1364+ messages in thread
From: Satyaki Das @ 2003-01-05 8:12 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Emacs crash in X
2003-01-05 8:12 ` Emacs crash in X Satyaki Das
@ 2003-01-06 3:26 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-01-06 3:26 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Emacs crash in X
[not found] ` <rms@gnu.org>
2002-04-20 22:04 ` Nick
2003-01-05 8:12 ` Emacs crash in X Satyaki Das
@ 2003-01-06 9:07 ` Satyaki Das
[not found] ` <E194OUB-0006Mz-00@fencepost.gnu.org>
2003-10-20 22:27 ` RMAIL, MIME-related bug Peter S Galbraith
4 siblings, 0 replies; 1364+ messages in thread
From: Satyaki Das @ 2003-01-06 9:07 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: etags -f /dev/stdout enhancement request
@ 2003-01-07 12:40 ` Francesco Potorti`
2003-01-07 17:16 ` Lyndon Nerenberg
0 siblings, 1 reply; 1364+ messages in thread
From: Francesco Potorti` @ 2003-01-07 12:40 UTC (permalink / raw
Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: etags -f /dev/stdout enhancement request
2003-01-07 12:40 ` etags -f /dev/stdout enhancement request Francesco Potorti`
@ 2003-01-07 17:16 ` Lyndon Nerenberg
0 siblings, 0 replies; 1364+ messages in thread
From: Lyndon Nerenberg @ 2003-01-07 17:16 UTC (permalink / raw
Cc: Emacs developers
>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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* `whitespace-describe' function missing
@ 2003-04-11 17:21 ` Robert J. Chassell
2003-04-14 2:01 ` Rajesh Vaidheeswarran
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2003-04-11 17:21 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [bob@rattlesnake.com: `whitespace-describe' function missing]
[not found] ` <E194OUB-0006Mz-00@fencepost.gnu.org>
@ 2003-04-13 14:41 ` Rajesh Vaidheeswarran
0 siblings, 0 replies; 1364+ messages in thread
From: Rajesh Vaidheeswarran @ 2003-04-13 14:41 UTC (permalink / raw
Cc: emacs-devel
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 -------
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: `whitespace-describe' function missing
2003-04-11 17:21 ` `whitespace-describe' function missing Robert J. Chassell
@ 2003-04-14 2:01 ` Rajesh Vaidheeswarran
2003-04-14 11:55 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Rajesh Vaidheeswarran @ 2003-04-14 2:01 UTC (permalink / raw
Cc: emacs-devel
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
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: `whitespace-describe' function missing
2003-04-14 2:01 ` Rajesh Vaidheeswarran
@ 2003-04-14 11:55 ` Robert J. Chassell
2003-04-14 15:23 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2003-04-14 11:55 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: `whitespace-describe' function missing
2003-04-14 11:55 ` Robert J. Chassell
@ 2003-04-14 15:23 ` Kim F. Storm
2003-05-13 14:38 ` Rajesh Vaidheeswarran
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2003-04-14 15:23 UTC (permalink / raw
Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: `whitespace-describe' function missing
2003-04-14 15:23 ` Kim F. Storm
@ 2003-05-13 14:38 ` Rajesh Vaidheeswarran
2003-05-13 15:30 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Rajesh Vaidheeswarran @ 2003-05-13 14:38 UTC (permalink / raw
Cc: emacs-devel
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
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: `whitespace-describe' function missing
2003-05-13 14:38 ` Rajesh Vaidheeswarran
@ 2003-05-13 15:30 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-05-13 15:30 UTC (permalink / raw
Cc: Kim F. Storm
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* S-backspace
@ 2003-05-25 23:01 Alex Schroeder
2003-05-25 23:57 ` S-backspace Miles Bader
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Alex Schroeder @ 2003-05-25 23:01 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-25 23:01 S-backspace Alex Schroeder
@ 2003-05-25 23:57 ` Miles Bader
2003-05-26 1:14 ` S-backspace Luc Teirlinck
2003-05-26 15:18 ` S-backspace Kai Großjohann
2003-05-27 12:44 ` S-backspace Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2003-05-25 23:57 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-25 23:57 ` S-backspace Miles Bader
@ 2003-05-26 1:14 ` Luc Teirlinck
[not found] ` <200305260121.h4Q1L0s14572@eel.dms.auburn.edu>
2003-05-26 14:24 ` S-backspace Oliver Scholz
0 siblings, 2 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-26 1:14 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
[not found] ` <200305260121.h4Q1L0s14572@eel.dms.auburn.edu>
@ 2003-05-26 1:24 ` Luc Teirlinck
2003-05-26 1:38 ` S-backspace Luc Teirlinck
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-26 1:24 UTC (permalink / raw
Cc: miles
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-26 1:24 ` S-backspace Luc Teirlinck
@ 2003-05-26 1:38 ` Luc Teirlinck
0 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-26 1:38 UTC (permalink / raw
Cc: miles
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-26 1:14 ` S-backspace Luc Teirlinck
[not found] ` <200305260121.h4Q1L0s14572@eel.dms.auburn.edu>
@ 2003-05-26 14:24 ` Oliver Scholz
2003-05-26 18:59 ` S-backspace Luc Teirlinck
1 sibling, 1 reply; 1364+ messages in thread
From: Oliver Scholz @ 2003-05-26 14:24 UTC (permalink / raw
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é!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-25 23:01 S-backspace Alex Schroeder
2003-05-25 23:57 ` S-backspace Miles Bader
@ 2003-05-26 15:18 ` Kai Großjohann
2003-05-27 12:44 ` S-backspace Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2003-05-26 15:18 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-26 14:24 ` S-backspace Oliver Scholz
@ 2003-05-26 18:59 ` Luc Teirlinck
0 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-26 18:59 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-25 23:01 S-backspace Alex Schroeder
2003-05-25 23:57 ` S-backspace Miles Bader
2003-05-26 15:18 ` S-backspace Kai Großjohann
@ 2003-05-27 12:44 ` Richard Stallman
2003-05-27 13:57 ` S-backspace Kai Großjohann
2003-05-27 14:06 ` S-backspace Rajesh Vaidheeswarran
2 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-05-27 12:44 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 12:44 ` S-backspace Richard Stallman
@ 2003-05-27 13:57 ` Kai Großjohann
2003-05-27 14:06 ` S-backspace Rajesh Vaidheeswarran
1 sibling, 0 replies; 1364+ messages in thread
From: Kai Großjohann @ 2003-05-27 13:57 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 12:44 ` S-backspace Richard Stallman
2003-05-27 13:57 ` S-backspace Kai Großjohann
@ 2003-05-27 14:06 ` Rajesh Vaidheeswarran
2003-05-27 14:16 ` S-backspace David Kastrup
` (3 more replies)
1 sibling, 4 replies; 1364+ messages in thread
From: Rajesh Vaidheeswarran @ 2003-05-27 14:06 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 14:06 ` S-backspace Rajesh Vaidheeswarran
@ 2003-05-27 14:16 ` David Kastrup
2003-05-27 14:18 ` S-backspace Miles Bader
` (2 subsequent siblings)
3 siblings, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2003-05-27 14:16 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 14:06 ` S-backspace Rajesh Vaidheeswarran
2003-05-27 14:16 ` S-backspace David Kastrup
@ 2003-05-27 14:18 ` Miles Bader
2003-05-27 15:46 ` S-backspace Kai Großjohann
2003-05-27 16:26 ` S-backspace Luc Teirlinck
2003-05-27 14:31 ` S-backspace Jan D.
2003-05-28 13:54 ` S-backspace Richard Stallman
3 siblings, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2003-05-27 14:18 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 14:06 ` S-backspace Rajesh Vaidheeswarran
2003-05-27 14:16 ` S-backspace David Kastrup
2003-05-27 14:18 ` S-backspace Miles Bader
@ 2003-05-27 14:31 ` Jan D.
2003-05-28 13:54 ` S-backspace Richard Stallman
3 siblings, 0 replies; 1364+ messages in thread
From: Jan D. @ 2003-05-27 14:31 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 14:18 ` S-backspace Miles Bader
@ 2003-05-27 15:46 ` Kai Großjohann
2003-05-27 16:47 ` S-backspace Luc Teirlinck
2003-05-27 17:04 ` S-backspace Luc Teirlinck
2003-05-27 16:26 ` S-backspace Luc Teirlinck
1 sibling, 2 replies; 1364+ messages in thread
From: Kai Großjohann @ 2003-05-27 15:46 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 14:18 ` S-backspace Miles Bader
2003-05-27 15:46 ` S-backspace Kai Großjohann
@ 2003-05-27 16:26 ` Luc Teirlinck
2003-05-28 23:57 ` S-backspace Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-27 16:26 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 15:46 ` S-backspace Kai Großjohann
@ 2003-05-27 16:47 ` Luc Teirlinck
2003-05-27 17:06 ` S-backspace Stefan Monnier
2003-05-27 17:04 ` S-backspace Luc Teirlinck
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-27 16:47 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 15:46 ` S-backspace Kai Großjohann
2003-05-27 16:47 ` S-backspace Luc Teirlinck
@ 2003-05-27 17:04 ` Luc Teirlinck
1 sibling, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-27 17:04 UTC (permalink / raw
Cc: emacs-devel
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 16:47 ` S-backspace Luc Teirlinck
@ 2003-05-27 17:06 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-05-27 17:06 UTC (permalink / raw
Cc: kai.grossjohann
> 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'"
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 14:06 ` S-backspace Rajesh Vaidheeswarran
` (2 preceding siblings ...)
2003-05-27 14:31 ` S-backspace Jan D.
@ 2003-05-28 13:54 ` Richard Stallman
3 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-05-28 13:54 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-27 16:26 ` S-backspace Luc Teirlinck
@ 2003-05-28 23:57 ` Richard Stallman
2003-05-29 0:25 ` S-backspace Stefan Monnier
2003-05-29 1:46 ` S-backspace Luc Teirlinck
0 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-05-28 23:57 UTC (permalink / raw
Cc: miles
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-28 23:57 ` S-backspace Richard Stallman
@ 2003-05-29 0:25 ` Stefan Monnier
2003-05-29 2:33 ` S-backspace Peter Lee
` (2 more replies)
2003-05-29 1:46 ` S-backspace Luc Teirlinck
1 sibling, 3 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-05-29 0:25 UTC (permalink / raw
Cc: miles
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-28 23:57 ` S-backspace Richard Stallman
2003-05-29 0:25 ` S-backspace Stefan Monnier
@ 2003-05-29 1:46 ` Luc Teirlinck
2003-05-29 2:11 ` S-backspace Luc Teirlinck
2003-05-30 17:12 ` S-backspace Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-29 1:46 UTC (permalink / raw
Cc: miles
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-29 1:46 ` S-backspace Luc Teirlinck
@ 2003-05-29 2:11 ` Luc Teirlinck
2003-05-30 17:12 ` S-backspace Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-29 2:11 UTC (permalink / raw
Cc: miles
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-29 0:25 ` S-backspace Stefan Monnier
@ 2003-05-29 2:33 ` Peter Lee
2003-05-29 7:54 ` S-backspace Oliver Scholz
2003-05-31 19:44 ` S-backspace David Kastrup
2 siblings, 0 replies; 1364+ messages in thread
From: Peter Lee @ 2003-05-29 2:33 UTC (permalink / raw
>>>> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-29 0:25 ` S-backspace Stefan Monnier
2003-05-29 2:33 ` S-backspace Peter Lee
@ 2003-05-29 7:54 ` Oliver Scholz
2003-05-30 1:10 ` S-backspace Luc Teirlinck
2003-05-31 19:44 ` S-backspace David Kastrup
2 siblings, 1 reply; 1364+ messages in thread
From: Oliver Scholz @ 2003-05-29 7:54 UTC (permalink / raw
"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é!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-29 7:54 ` S-backspace Oliver Scholz
@ 2003-05-30 1:10 ` Luc Teirlinck
2003-06-05 1:49 ` S-backspace Luc Teirlinck
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-30 1:10 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-29 1:46 ` S-backspace Luc Teirlinck
2003-05-29 2:11 ` S-backspace Luc Teirlinck
@ 2003-05-30 17:12 ` Richard Stallman
2003-05-30 22:22 ` S-backspace Kevin Rodgers
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-05-30 17:12 UTC (permalink / raw
Cc: miles
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-30 17:12 ` S-backspace Richard Stallman
@ 2003-05-30 22:22 ` Kevin Rodgers
2003-05-30 23:59 ` S-backspace Kim F. Storm
2003-05-31 0:39 ` S-backspace Luc Teirlinck
2 siblings, 0 replies; 1364+ messages in thread
From: Kevin Rodgers @ 2003-05-30 22:22 UTC (permalink / raw
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:<kevin.rodgers@ihs.com>">Kevin Rodgers</a>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-30 17:12 ` S-backspace Richard Stallman
2003-05-30 22:22 ` S-backspace Kevin Rodgers
@ 2003-05-30 23:59 ` Kim F. Storm
2003-06-04 11:13 ` S-backspace Andreas Schwab
2003-05-31 0:39 ` S-backspace Luc Teirlinck
2 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2003-05-30 23:59 UTC (permalink / raw
Cc: miles
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-30 17:12 ` S-backspace Richard Stallman
2003-05-30 22:22 ` S-backspace Kevin Rodgers
2003-05-30 23:59 ` S-backspace Kim F. Storm
@ 2003-05-31 0:39 ` Luc Teirlinck
2003-05-31 0:53 ` S-backspace Miles Bader
2 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-31 0:39 UTC (permalink / raw
Cc: miles
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-31 0:39 ` S-backspace Luc Teirlinck
@ 2003-05-31 0:53 ` Miles Bader
2003-05-31 0:58 ` S-backspace Luc Teirlinck
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2003-05-31 0:53 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-31 0:53 ` S-backspace Miles Bader
@ 2003-05-31 0:58 ` Luc Teirlinck
2003-05-31 1:07 ` S-backspace Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-05-31 0:58 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-31 0:58 ` S-backspace Luc Teirlinck
@ 2003-05-31 1:07 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2003-05-31 1:07 UTC (permalink / raw
Cc: emacs-devel
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'
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-29 0:25 ` S-backspace Stefan Monnier
2003-05-29 2:33 ` S-backspace Peter Lee
2003-05-29 7:54 ` S-backspace Oliver Scholz
@ 2003-05-31 19:44 ` David Kastrup
2 siblings, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2003-05-31 19:44 UTC (permalink / raw
Cc: miles
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-30 23:59 ` S-backspace Kim F. Storm
@ 2003-06-04 11:13 ` Andreas Schwab
0 siblings, 0 replies; 1364+ messages in thread
From: Andreas Schwab @ 2003-06-04 11:13 UTC (permalink / raw
Cc: miles
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-05-30 1:10 ` S-backspace Luc Teirlinck
@ 2003-06-05 1:49 ` Luc Teirlinck
2003-06-05 2:40 ` S-backspace Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-06-05 1:49 UTC (permalink / raw
Cc: alkibiades
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: S-backspace
2003-06-05 1:49 ` S-backspace Luc Teirlinck
@ 2003-06-05 2:40 ` Miles Bader
2003-06-05 3:12 ` { SPAM 2 }::Re: S-backspace Luc Teirlinck
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2003-06-05 2:40 UTC (permalink / raw
Cc: alkibiades
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: { SPAM 2 }::Re: S-backspace
2003-06-05 2:40 ` S-backspace Miles Bader
@ 2003-06-05 3:12 ` Luc Teirlinck
0 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-06-05 3:12 UTC (permalink / raw
Cc: alkibiades
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
@ 2003-10-12 19:47 Alexander Pohoyda
2003-10-14 1:50 ` Kenichi Handa
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-12 19:47 UTC (permalink / raw
Cc: emacs-devel
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-12 19:47 RMAIL, MIME-related bug Alexander Pohoyda
@ 2003-10-14 1:50 ` Kenichi Handa
2003-10-14 14:05 ` Robert J. Chassell
2003-10-16 6:59 ` Eli Zaretskii
2003-10-16 16:54 ` Stefan Monnier
2 siblings, 1 reply; 1364+ messages in thread
From: Kenichi Handa @ 2003-10-14 1:50 UTC (permalink / raw
Cc: eliz, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-14 1:50 ` Kenichi Handa
@ 2003-10-14 14:05 ` Robert J. Chassell
[not found] ` <bob@rattlesnake.com>
2003-10-15 4:08 ` RMAIL, MIME-related bug Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2003-10-14 14:05 UTC (permalink / raw
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-14 14:05 ` Robert J. Chassell
[not found] ` <bob@rattlesnake.com>
@ 2003-10-15 4:08 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-15 4:08 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
[not found] ` <bob@rattlesnake.com>
2003-04-11 17:21 ` `whitespace-describe' function missing Robert J. Chassell
@ 2003-10-15 19:59 ` Peter S Galbraith
2005-05-04 19:59 ` bootstrap from scratch Robert J. Chassell
2 siblings, 0 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2003-10-15 19:59 UTC (permalink / raw
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.)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-12 19:47 RMAIL, MIME-related bug Alexander Pohoyda
2003-10-14 1:50 ` Kenichi Handa
@ 2003-10-16 6:59 ` Eli Zaretskii
2003-10-16 7:41 ` Alexander Pohoyda
2003-10-16 23:06 ` Richard Stallman
2003-10-16 16:54 ` Stefan Monnier
2 siblings, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-16 6:59 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 6:59 ` Eli Zaretskii
@ 2003-10-16 7:41 ` Alexander Pohoyda
2003-10-16 9:40 ` Thien-Thi Nguyen
` (2 more replies)
2003-10-16 23:06 ` Richard Stallman
1 sibling, 3 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-16 7:41 UTC (permalink / raw
Cc: emacs-devel
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 7:41 ` Alexander Pohoyda
@ 2003-10-16 9:40 ` Thien-Thi Nguyen
2003-10-16 9:48 ` Thien-Thi Nguyen
2003-10-16 13:27 ` Alexander Pohoyda
2003-10-16 11:20 ` Eli Zaretskii
2003-10-16 23:06 ` Richard Stallman
2 siblings, 2 replies; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2003-10-16 9:40 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 9:40 ` Thien-Thi Nguyen
@ 2003-10-16 9:48 ` Thien-Thi Nguyen
2003-10-16 13:27 ` Alexander Pohoyda
1 sibling, 0 replies; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2003-10-16 9:48 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 7:41 ` Alexander Pohoyda
2003-10-16 9:40 ` Thien-Thi Nguyen
@ 2003-10-16 11:20 ` Eli Zaretskii
2003-10-16 13:14 ` Alexander Pohoyda
2003-10-16 14:36 ` Ehud Karni
2003-10-16 23:06 ` Richard Stallman
2 siblings, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-16 11:20 UTC (permalink / raw
Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 11:20 ` Eli Zaretskii
@ 2003-10-16 13:14 ` Alexander Pohoyda
2003-10-16 16:02 ` Eli Zaretskii
2003-10-16 14:36 ` Ehud Karni
1 sibling, 1 reply; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-16 13:14 UTC (permalink / raw
Cc: emacs-devel
> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 9:40 ` Thien-Thi Nguyen
2003-10-16 9:48 ` Thien-Thi Nguyen
@ 2003-10-16 13:27 ` Alexander Pohoyda
2003-10-16 14:15 ` Thien-Thi Nguyen
1 sibling, 1 reply; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-16 13:27 UTC (permalink / raw
Cc: eliz, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 13:27 ` Alexander Pohoyda
@ 2003-10-16 14:15 ` Thien-Thi Nguyen
0 siblings, 0 replies; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2003-10-16 14:15 UTC (permalink / raw
Cc: eliz, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 11:20 ` Eli Zaretskii
2003-10-16 13:14 ` Alexander Pohoyda
@ 2003-10-16 14:36 ` Ehud Karni
2003-10-16 16:06 ` Eli Zaretskii
1 sibling, 1 reply; 1364+ messages in thread
From: Ehud Karni @ 2003-10-16 14:36 UTC (permalink / raw
Cc: emacs-devel
-----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-----
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 13:14 ` Alexander Pohoyda
@ 2003-10-16 16:02 ` Eli Zaretskii
2003-10-16 18:27 ` David Kastrup
2003-10-16 21:18 ` Alexander Pohoyda
0 siblings, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-16 16:02 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 14:36 ` Ehud Karni
@ 2003-10-16 16:06 ` Eli Zaretskii
0 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-16 16:06 UTC (permalink / raw
Cc: alexander.pohoyda, emacs-devel
> 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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-12 19:47 RMAIL, MIME-related bug Alexander Pohoyda
2003-10-14 1:50 ` Kenichi Handa
2003-10-16 6:59 ` Eli Zaretskii
@ 2003-10-16 16:54 ` Stefan Monnier
2003-10-16 17:21 ` Eli Zaretskii
` (3 more replies)
2 siblings, 4 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-10-16 16:54 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 16:54 ` Stefan Monnier
@ 2003-10-16 17:21 ` Eli Zaretskii
2003-10-16 18:49 ` Stefan Monnier
` (2 more replies)
2003-10-16 21:44 ` RMAIL, MIME-related bug Alexander Pohoyda
` (2 subsequent siblings)
3 siblings, 3 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-16 17:21 UTC (permalink / raw
Cc: alexander.pohoyda, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 16:02 ` Eli Zaretskii
@ 2003-10-16 18:27 ` David Kastrup
2003-10-16 21:18 ` Alexander Pohoyda
1 sibling, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2003-10-16 18:27 UTC (permalink / raw
Cc: Alexander Pohoyda, emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 17:21 ` Eli Zaretskii
@ 2003-10-16 18:49 ` Stefan Monnier
2003-10-16 18:58 ` Eli Zaretskii
2003-10-16 19:14 ` Ehud Karni
[not found] ` <eliz@elta.co.il>
2003-10-17 20:46 ` Richard Stallman
2 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-10-16 18:49 UTC (permalink / raw
Cc: alexander.pohoyda, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 18:49 ` Stefan Monnier
@ 2003-10-16 18:58 ` Eli Zaretskii
2003-10-16 19:21 ` Stefan Monnier
2003-10-16 19:33 ` RMAIL, MIME-related bug Ehud Karni
2003-10-16 19:14 ` Ehud Karni
1 sibling, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-16 18:58 UTC (permalink / raw
Cc: alexander.pohoyda, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 18:49 ` Stefan Monnier
2003-10-16 18:58 ` Eli Zaretskii
@ 2003-10-16 19:14 ` Ehud Karni
2003-10-16 21:56 ` Alexander Pohoyda
1 sibling, 1 reply; 1364+ messages in thread
From: Ehud Karni @ 2003-10-16 19:14 UTC (permalink / raw
Cc: emacs-devel
-----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-----
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 18:58 ` Eli Zaretskii
@ 2003-10-16 19:21 ` Stefan Monnier
2003-10-17 6:24 ` Eli Zaretskii
2003-10-16 19:33 ` RMAIL, MIME-related bug Ehud Karni
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-10-16 19:21 UTC (permalink / raw
Cc: alexander.pohoyda, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 18:58 ` Eli Zaretskii
2003-10-16 19:21 ` Stefan Monnier
@ 2003-10-16 19:33 ` Ehud Karni
2003-10-17 6:20 ` Eli Zaretskii
1 sibling, 1 reply; 1364+ messages in thread
From: Ehud Karni @ 2003-10-16 19:33 UTC (permalink / raw
Cc: monnier, alexander.pohoyda, emacs-devel
-----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-----
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 16:02 ` Eli Zaretskii
2003-10-16 18:27 ` David Kastrup
@ 2003-10-16 21:18 ` Alexander Pohoyda
2003-10-17 7:00 ` Eli Zaretskii
1 sibling, 1 reply; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-16 21:18 UTC (permalink / raw
Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 16:54 ` Stefan Monnier
2003-10-16 17:21 ` Eli Zaretskii
@ 2003-10-16 21:44 ` Alexander Pohoyda
2003-10-16 22:07 ` Stefan Monnier
2003-10-16 21:44 ` Alexander Pohoyda
2003-10-19 20:59 ` Juri Linkov
3 siblings, 1 reply; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-16 21:44 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 16:54 ` Stefan Monnier
2003-10-16 17:21 ` Eli Zaretskii
2003-10-16 21:44 ` RMAIL, MIME-related bug Alexander Pohoyda
@ 2003-10-16 21:44 ` Alexander Pohoyda
2003-10-19 20:59 ` Juri Linkov
3 siblings, 0 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-16 21:44 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 19:14 ` Ehud Karni
@ 2003-10-16 21:56 ` Alexander Pohoyda
2003-10-16 22:21 ` Ehud Karni
0 siblings, 1 reply; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-16 21:56 UTC (permalink / raw
Cc: eliz, monnier, emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 21:44 ` RMAIL, MIME-related bug Alexander Pohoyda
@ 2003-10-16 22:07 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-10-16 22:07 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 21:56 ` Alexander Pohoyda
@ 2003-10-16 22:21 ` Ehud Karni
2003-10-16 23:48 ` Luc Teirlinck
0 siblings, 1 reply; 1364+ messages in thread
From: Ehud Karni @ 2003-10-16 22:21 UTC (permalink / raw
Cc: eliz, monnier, emacs-devel
-----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-----
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 6:59 ` Eli Zaretskii
2003-10-16 7:41 ` Alexander Pohoyda
@ 2003-10-16 23:06 ` Richard Stallman
2003-10-17 6:19 ` Alexander Pohoyda
2003-10-17 6:45 ` Eli Zaretskii
1 sibling, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-16 23:06 UTC (permalink / raw
Cc: alexander.pohoyda, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 7:41 ` Alexander Pohoyda
2003-10-16 9:40 ` Thien-Thi Nguyen
2003-10-16 11:20 ` Eli Zaretskii
@ 2003-10-16 23:06 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-16 23:06 UTC (permalink / raw
Cc: eliz, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 22:21 ` Ehud Karni
@ 2003-10-16 23:48 ` Luc Teirlinck
2003-10-17 2:20 ` Kenichi Handa
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-10-16 23:48 UTC (permalink / raw
Cc: eliz, monnier, alexander.pohoyda, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 23:48 ` Luc Teirlinck
@ 2003-10-17 2:20 ` Kenichi Handa
0 siblings, 0 replies; 1364+ messages in thread
From: Kenichi Handa @ 2003-10-17 2:20 UTC (permalink / raw
Cc: ehud, emacs-devel, eliz, alexander.pohoyda, monnier
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
[not found] ` <eliz@elta.co.il>
@ 2003-10-17 2:36 ` Peter S Galbraith
2003-10-17 15:39 ` Peter S Galbraith
2003-10-17 18:33 ` Peter S Galbraith
2 siblings, 0 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2003-10-17 2:36 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 23:06 ` Richard Stallman
@ 2003-10-17 6:19 ` Alexander Pohoyda
2003-10-17 6:45 ` Eli Zaretskii
1 sibling, 0 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-17 6:19 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 19:33 ` RMAIL, MIME-related bug Ehud Karni
@ 2003-10-17 6:20 ` Eli Zaretskii
0 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-17 6:20 UTC (permalink / raw
Cc: monnier, alexander.pohoyda, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 19:21 ` Stefan Monnier
@ 2003-10-17 6:24 ` Eli Zaretskii
2003-10-17 11:54 ` Stephen J. Turnbull
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-17 6:24 UTC (permalink / raw
Cc: alexander.pohoyda, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 23:06 ` Richard Stallman
2003-10-17 6:19 ` Alexander Pohoyda
@ 2003-10-17 6:45 ` Eli Zaretskii
1 sibling, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-17 6:45 UTC (permalink / raw
Cc: alexander.pohoyda, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 21:18 ` Alexander Pohoyda
@ 2003-10-17 7:00 ` Eli Zaretskii
0 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-17 7:00 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 6:24 ` Eli Zaretskii
@ 2003-10-17 11:54 ` Stephen J. Turnbull
2003-10-17 18:10 ` Eli Zaretskii
2003-10-17 18:51 ` Satyaki Das
2003-10-17 18:57 ` Lars Magne Ingebrigtsen
2 siblings, 1 reply; 1364+ messages in thread
From: Stephen J. Turnbull @ 2003-10-17 11:54 UTC (permalink / raw
Cc: emacs-devel
>>>>> "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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
[not found] ` <eliz@elta.co.il>
2003-10-17 2:36 ` Peter S Galbraith
@ 2003-10-17 15:39 ` Peter S Galbraith
2003-10-17 16:16 ` Stefan Monnier
2003-10-17 18:17 ` Eli Zaretskii
2003-10-17 18:33 ` Peter S Galbraith
2 siblings, 2 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2003-10-17 15:39 UTC (permalink / raw
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 15:39 ` Peter S Galbraith
@ 2003-10-17 16:16 ` Stefan Monnier
[not found] ` <monnier@IRO.UMontreal.CA>
2003-10-17 18:17 ` Eli Zaretskii
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-10-17 16:16 UTC (permalink / raw
Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
[not found] ` <monnier@IRO.UMontreal.CA>
@ 2003-10-17 16:22 ` Peter S Galbraith
0 siblings, 0 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2003-10-17 16:22 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 11:54 ` Stephen J. Turnbull
@ 2003-10-17 18:10 ` Eli Zaretskii
2003-10-21 3:09 ` Stephen J. Turnbull
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-17 18:10 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 15:39 ` Peter S Galbraith
2003-10-17 16:16 ` Stefan Monnier
@ 2003-10-17 18:17 ` Eli Zaretskii
1 sibling, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-17 18:17 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
[not found] ` <eliz@elta.co.il>
2003-10-17 2:36 ` Peter S Galbraith
2003-10-17 15:39 ` Peter S Galbraith
@ 2003-10-17 18:33 ` Peter S Galbraith
2003-10-20 10:43 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Peter S Galbraith @ 2003-10-17 18:33 UTC (permalink / raw
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 6:24 ` Eli Zaretskii
2003-10-17 11:54 ` Stephen J. Turnbull
@ 2003-10-17 18:51 ` Satyaki Das
2003-10-17 18:57 ` Lars Magne Ingebrigtsen
2 siblings, 0 replies; 1364+ messages in thread
From: Satyaki Das @ 2003-10-17 18:51 UTC (permalink / raw
Cc: Stefan Monnier, alexander.pohoyda, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 6:24 ` Eli Zaretskii
2003-10-17 11:54 ` Stephen J. Turnbull
2003-10-17 18:51 ` Satyaki Das
@ 2003-10-17 18:57 ` Lars Magne Ingebrigtsen
2003-10-18 8:29 ` Eli Zaretskii
2 siblings, 1 reply; 1364+ messages in thread
From: Lars Magne Ingebrigtsen @ 2003-10-17 18:57 UTC (permalink / raw
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 17:21 ` Eli Zaretskii
2003-10-16 18:49 ` Stefan Monnier
[not found] ` <eliz@elta.co.il>
@ 2003-10-17 20:46 ` Richard Stallman
2003-10-17 21:09 ` Stefan Monnier
2 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-10-17 20:46 UTC (permalink / raw
Cc: monnier, alexander.pohoyda, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 20:46 ` Richard Stallman
@ 2003-10-17 21:09 ` Stefan Monnier
2003-10-18 23:06 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-10-17 21:09 UTC (permalink / raw
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 18:57 ` Lars Magne Ingebrigtsen
@ 2003-10-18 8:29 ` Eli Zaretskii
2003-10-18 23:05 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-18 8:29 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-18 8:29 ` Eli Zaretskii
@ 2003-10-18 23:05 ` Richard Stallman
2003-10-19 5:50 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-10-18 23:05 UTC (permalink / raw
Cc: larsi, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 21:09 ` Stefan Monnier
@ 2003-10-18 23:06 ` Richard Stallman
2003-10-19 7:46 ` Alexander Pohoyda
2003-10-22 20:26 ` RMAIL, rmail-mbox-branch Alexander Pohoyda
0 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-18 23:06 UTC (permalink / raw
Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* customizing a variable named in Info
@ 2003-10-19 1:34 Peter S Galbraith
2003-10-19 5:58 ` Eli Zaretskii
2003-10-20 1:48 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2003-10-19 1:34 UTC (permalink / raw
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-18 23:05 ` Richard Stallman
@ 2003-10-19 5:50 ` Eli Zaretskii
2003-10-19 10:38 ` Alex Schroeder
2003-10-20 1:48 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-19 5:50 UTC (permalink / raw
Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: customizing a variable named in Info
2003-10-19 1:34 customizing a variable named in Info Peter S Galbraith
@ 2003-10-19 5:58 ` Eli Zaretskii
2003-10-19 15:12 ` Luc Teirlinck
2003-10-20 1:48 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2003-10-19 5:58 UTC (permalink / raw
Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-18 23:06 ` Richard Stallman
@ 2003-10-19 7:46 ` Alexander Pohoyda
2003-10-22 20:26 ` RMAIL, rmail-mbox-branch Alexander Pohoyda
1 sibling, 0 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-19 7:46 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-19 5:50 ` Eli Zaretskii
@ 2003-10-19 10:38 ` Alex Schroeder
2003-10-20 1:48 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Alex Schroeder @ 2003-10-19 10:38 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: customizing a variable named in Info
2003-10-19 5:58 ` Eli Zaretskii
@ 2003-10-19 15:12 ` Luc Teirlinck
[not found] ` <teirllm@dms.auburn.edu>
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-10-19 15:12 UTC (permalink / raw
Cc: p.galbraith, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: customizing a variable named in Info
[not found] ` <teirllm@dms.auburn.edu>
@ 2003-10-19 17:17 ` Peter S Galbraith
0 siblings, 0 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2003-10-19 17:17 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-16 16:54 ` Stefan Monnier
` (2 preceding siblings ...)
2003-10-16 21:44 ` Alexander Pohoyda
@ 2003-10-19 20:59 ` Juri Linkov
2003-10-20 4:18 ` Kenichi Handa
` (4 more replies)
3 siblings, 5 replies; 1364+ messages in thread
From: Juri Linkov @ 2003-10-19 20:59 UTC (permalink / raw
Cc: emacs-devel
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: customizing a variable named in Info
2003-10-19 1:34 customizing a variable named in Info Peter S Galbraith
2003-10-19 5:58 ` Eli Zaretskii
@ 2003-10-20 1:48 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-20 1:48 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-19 5:50 ` Eli Zaretskii
2003-10-19 10:38 ` Alex Schroeder
@ 2003-10-20 1:48 ` Richard Stallman
2003-10-20 5:53 ` Alexander Pohoyda
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-10-20 1:48 UTC (permalink / raw
Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-19 20:59 ` Juri Linkov
@ 2003-10-20 4:18 ` Kenichi Handa
2003-10-20 5:15 ` Juri Linkov
` (2 more replies)
2003-10-20 6:54 ` Lars Magne Ingebrigtsen
` (3 subsequent siblings)
4 siblings, 3 replies; 1364+ messages in thread
From: Kenichi Handa @ 2003-10-20 4:18 UTC (permalink / raw
Cc: monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 4:18 ` Kenichi Handa
@ 2003-10-20 5:15 ` Juri Linkov
2003-10-20 5:21 ` Alexander Pohoyda
2003-10-20 13:03 ` Robert J. Chassell
2 siblings, 0 replies; 1364+ messages in thread
From: Juri Linkov @ 2003-10-20 5:15 UTC (permalink / raw
Cc: emacs-devel
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 4:18 ` Kenichi Handa
2003-10-20 5:15 ` Juri Linkov
@ 2003-10-20 5:21 ` Alexander Pohoyda
2003-10-20 13:03 ` Robert J. Chassell
2 siblings, 0 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-20 5:21 UTC (permalink / raw
Cc: juri, monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 1:48 ` Richard Stallman
@ 2003-10-20 5:53 ` Alexander Pohoyda
2003-10-20 6:51 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-20 5:53 UTC (permalink / raw
Cc: Eli Zaretskii, larsi, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 5:53 ` Alexander Pohoyda
@ 2003-10-20 6:51 ` Lars Magne Ingebrigtsen
2003-10-20 17:39 ` Alexander Pohoyda
2003-10-20 23:20 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Lars Magne Ingebrigtsen @ 2003-10-20 6:51 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-19 20:59 ` Juri Linkov
2003-10-20 4:18 ` Kenichi Handa
@ 2003-10-20 6:54 ` Lars Magne Ingebrigtsen
2003-10-20 8:11 ` Juri Linkov
2003-10-20 13:56 ` Paul Michael Reilly
2003-10-20 17:14 ` Satyaki Das
` (2 subsequent siblings)
4 siblings, 2 replies; 1364+ messages in thread
From: Lars Magne Ingebrigtsen @ 2003-10-20 6:54 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 6:54 ` Lars Magne Ingebrigtsen
@ 2003-10-20 8:11 ` Juri Linkov
2003-10-20 9:33 ` Lars Magne Ingebrigtsen
2003-10-20 13:56 ` Paul Michael Reilly
1 sibling, 1 reply; 1364+ messages in thread
From: Juri Linkov @ 2003-10-20 8:11 UTC (permalink / raw
Cc: emacs-devel
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 8:11 ` Juri Linkov
@ 2003-10-20 9:33 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 1364+ messages in thread
From: Lars Magne Ingebrigtsen @ 2003-10-20 9:33 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 18:33 ` Peter S Galbraith
@ 2003-10-20 10:43 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-20 10:43 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 4:18 ` Kenichi Handa
2003-10-20 5:15 ` Juri Linkov
2003-10-20 5:21 ` Alexander Pohoyda
@ 2003-10-20 13:03 ` Robert J. Chassell
2 siblings, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2003-10-20 13:03 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 6:54 ` Lars Magne Ingebrigtsen
2003-10-20 8:11 ` Juri Linkov
@ 2003-10-20 13:56 ` Paul Michael Reilly
1 sibling, 0 replies; 1364+ messages in thread
From: Paul Michael Reilly @ 2003-10-20 13:56 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-19 20:59 ` Juri Linkov
2003-10-20 4:18 ` Kenichi Handa
2003-10-20 6:54 ` Lars Magne Ingebrigtsen
@ 2003-10-20 17:14 ` Satyaki Das
2003-10-21 14:48 ` Richard Stallman
2003-10-20 23:20 ` Richard Stallman
2003-10-20 23:38 ` Kevin Rodgers
4 siblings, 1 reply; 1364+ messages in thread
From: Satyaki Das @ 2003-10-20 17:14 UTC (permalink / raw
Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 6:51 ` Lars Magne Ingebrigtsen
@ 2003-10-20 17:39 ` Alexander Pohoyda
2003-10-20 23:20 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-20 17:39 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
[not found] ` <rms@gnu.org>
` (3 preceding siblings ...)
[not found] ` <E194OUB-0006Mz-00@fencepost.gnu.org>
@ 2003-10-20 22:27 ` Peter S Galbraith
4 siblings, 0 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2003-10-20 22:27 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-19 20:59 ` Juri Linkov
` (2 preceding siblings ...)
2003-10-20 17:14 ` Satyaki Das
@ 2003-10-20 23:20 ` Richard Stallman
2003-10-21 5:30 ` Karl Eichwalder
2003-10-20 23:38 ` Kevin Rodgers
4 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-10-20 23:20 UTC (permalink / raw
Cc: monnier, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 6:51 ` Lars Magne Ingebrigtsen
2003-10-20 17:39 ` Alexander Pohoyda
@ 2003-10-20 23:20 ` Richard Stallman
2003-12-26 17:40 ` Merging quoted-printable functions Alexander Pohoyda
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-10-20 23:20 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-19 20:59 ` Juri Linkov
` (3 preceding siblings ...)
2003-10-20 23:20 ` Richard Stallman
@ 2003-10-20 23:38 ` Kevin Rodgers
2003-10-21 5:38 ` Juri Linkov
4 siblings, 1 reply; 1364+ messages in thread
From: Kevin Rodgers @ 2003-10-20 23:38 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-17 18:10 ` Eli Zaretskii
@ 2003-10-21 3:09 ` Stephen J. Turnbull
2003-10-21 3:59 ` Simon Josefsson
2003-10-22 9:25 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Stephen J. Turnbull @ 2003-10-21 3:09 UTC (permalink / raw
Cc: emacs-devel
>>>>> "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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-21 3:09 ` Stephen J. Turnbull
@ 2003-10-21 3:59 ` Simon Josefsson
2003-10-21 10:50 ` Stephen J. Turnbull
2003-10-22 9:25 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Simon Josefsson @ 2003-10-21 3:59 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
"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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 23:20 ` Richard Stallman
@ 2003-10-21 5:30 ` Karl Eichwalder
2003-10-22 9:25 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Karl Eichwalder @ 2003-10-21 5:30 UTC (permalink / raw
Cc: Juri Linkov, monnier, emacs-devel
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/ | (*)/'(*)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 23:38 ` Kevin Rodgers
@ 2003-10-21 5:38 ` Juri Linkov
2003-10-21 14:40 ` URL (was: RMAIL, MIME-related bug) Stefan Monnier
2003-10-23 18:24 ` RMAIL, MIME-related bug Kevin Rodgers
0 siblings, 2 replies; 1364+ messages in thread
From: Juri Linkov @ 2003-10-21 5:38 UTC (permalink / raw
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-21 3:59 ` Simon Josefsson
@ 2003-10-21 10:50 ` Stephen J. Turnbull
2003-10-21 11:56 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 1364+ messages in thread
From: Stephen J. Turnbull @ 2003-10-21 10:50 UTC (permalink / raw
Cc: Eli Zaretskii, emacs-devel
>>>>> "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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-21 10:50 ` Stephen J. Turnbull
@ 2003-10-21 11:56 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 1364+ messages in thread
From: Lars Magne Ingebrigtsen @ 2003-10-21 11:56 UTC (permalink / raw
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* URL (was: RMAIL, MIME-related bug)
2003-10-21 5:38 ` Juri Linkov
@ 2003-10-21 14:40 ` Stefan Monnier
2003-10-23 15:48 ` URL Dave Love
2003-10-23 18:24 ` RMAIL, MIME-related bug Kevin Rodgers
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-10-21 14:40 UTC (permalink / raw
Cc: fx, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-20 17:14 ` Satyaki Das
@ 2003-10-21 14:48 ` Richard Stallman
2003-10-21 16:48 ` Satyaki Das
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-10-21 14:48 UTC (permalink / raw
Cc: juri, monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-21 14:48 ` Richard Stallman
@ 2003-10-21 16:48 ` Satyaki Das
0 siblings, 0 replies; 1364+ messages in thread
From: Satyaki Das @ 2003-10-21 16:48 UTC (permalink / raw
Cc: juri, monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-21 3:09 ` Stephen J. Turnbull
2003-10-21 3:59 ` Simon Josefsson
@ 2003-10-22 9:25 ` Richard Stallman
2003-10-22 10:52 ` Stephen J. Turnbull
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-22 9:25 UTC (permalink / raw
Cc: eliz, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-21 5:30 ` Karl Eichwalder
@ 2003-10-22 9:25 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-22 9:25 UTC (permalink / raw
Cc: juri, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-22 9:25 ` Richard Stallman
@ 2003-10-22 10:52 ` Stephen J. Turnbull
2003-10-22 10:52 ` Kenichi Handa
2003-10-22 17:19 ` Alexander Pohoyda
2 siblings, 0 replies; 1364+ messages in thread
From: Stephen J. Turnbull @ 2003-10-22 10:52 UTC (permalink / raw
Cc: Stephen J. Turnbull, eliz, emacs-devel
>>>>> "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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-22 9:25 ` Richard Stallman
2003-10-22 10:52 ` Stephen J. Turnbull
@ 2003-10-22 10:52 ` Kenichi Handa
2003-10-29 11:30 ` 守岡知彦 / MORIOKA Tomohiko
2003-10-22 17:19 ` Alexander Pohoyda
2 siblings, 1 reply; 1364+ messages in thread
From: Kenichi Handa @ 2003-10-22 10:52 UTC (permalink / raw
Cc: stephen, tomo, eliz, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-22 9:25 ` Richard Stallman
2003-10-22 10:52 ` Stephen J. Turnbull
2003-10-22 10:52 ` Kenichi Handa
@ 2003-10-22 17:19 ` Alexander Pohoyda
2003-10-22 19:53 ` Lars Magne Ingebrigtsen
2003-10-22 23:47 ` Kenichi Handa
2 siblings, 2 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-22 17:19 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-22 17:19 ` Alexander Pohoyda
@ 2003-10-22 19:53 ` Lars Magne Ingebrigtsen
2003-10-22 23:47 ` Kenichi Handa
1 sibling, 0 replies; 1364+ messages in thread
From: Lars Magne Ingebrigtsen @ 2003-10-22 19:53 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, rmail-mbox-branch
2003-10-18 23:06 ` Richard Stallman
2003-10-19 7:46 ` Alexander Pohoyda
@ 2003-10-22 20:26 ` Alexander Pohoyda
2003-10-27 23:44 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-10-22 20:26 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-22 17:19 ` Alexander Pohoyda
2003-10-22 19:53 ` Lars Magne Ingebrigtsen
@ 2003-10-22 23:47 ` Kenichi Handa
1 sibling, 0 replies; 1364+ messages in thread
From: Kenichi Handa @ 2003-10-22 23:47 UTC (permalink / raw
Cc: rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: URL
2003-10-21 14:40 ` URL (was: RMAIL, MIME-related bug) Stefan Monnier
@ 2003-10-23 15:48 ` Dave Love
2003-10-23 16:31 ` URL Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Dave Love @ 2003-10-23 15:48 UTC (permalink / raw
Cc: Juri Linkov, wmperry, emacs-devel
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.]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: URL
2003-10-23 15:48 ` URL Dave Love
@ 2003-10-23 16:31 ` Stefan Monnier
2003-10-24 5:16 ` URL Richard Stallman
2003-10-25 16:20 ` URL Dave Love
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-10-23 16:31 UTC (permalink / raw
Cc: Juri Linkov, wmperry, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-21 5:38 ` Juri Linkov
2003-10-21 14:40 ` URL (was: RMAIL, MIME-related bug) Stefan Monnier
@ 2003-10-23 18:24 ` Kevin Rodgers
2003-10-23 19:57 ` Kevin Rodgers
1 sibling, 1 reply; 1364+ messages in thread
From: Kevin Rodgers @ 2003-10-23 18:24 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-23 18:24 ` RMAIL, MIME-related bug Kevin Rodgers
@ 2003-10-23 19:57 ` Kevin Rodgers
2003-10-27 13:03 ` URL Juri Linkov
0 siblings, 1 reply; 1364+ messages in thread
From: Kevin Rodgers @ 2003-10-23 19:57 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: URL
2003-10-23 16:31 ` URL Stefan Monnier
@ 2003-10-24 5:16 ` Richard Stallman
2003-10-25 16:20 ` URL Dave Love
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-10-24 5:16 UTC (permalink / raw
Cc: juri, emacs-devel, d.love, wmperry
>> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: URL
2003-10-23 16:31 ` URL Stefan Monnier
2003-10-24 5:16 ` URL Richard Stallman
@ 2003-10-25 16:20 ` Dave Love
2003-10-27 13:16 ` URL Juri Linkov
1 sibling, 1 reply; 1364+ messages in thread
From: Dave Love @ 2003-10-25 16:20 UTC (permalink / raw
Cc: Juri Linkov, wmperry, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: URL
2003-10-23 19:57 ` Kevin Rodgers
@ 2003-10-27 13:03 ` Juri Linkov
0 siblings, 0 replies; 1364+ messages in thread
From: Juri Linkov @ 2003-10-27 13:03 UTC (permalink / raw
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: URL
2003-10-25 16:20 ` URL Dave Love
@ 2003-10-27 13:16 ` Juri Linkov
0 siblings, 0 replies; 1364+ messages in thread
From: Juri Linkov @ 2003-10-27 13:16 UTC (permalink / raw
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, rmail-mbox-branch
2003-10-22 20:26 ` RMAIL, rmail-mbox-branch Alexander Pohoyda
@ 2003-10-27 23:44 ` Richard Stallman
2003-11-26 22:44 ` Alexander Pohoyda
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-10-27 23:44 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, MIME-related bug
2003-10-22 10:52 ` Kenichi Handa
@ 2003-10-29 11:30 ` 守岡知彦 / MORIOKA Tomohiko
0 siblings, 0 replies; 1364+ messages in thread
From: 守岡知彦 / MORIOKA Tomohiko @ 2003-10-29 11:30 UTC (permalink / raw
Cc: eliz, stephen, rms, emacs-devel
>>>>> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* doc elisp intro cross reference fixes
@ 2003-11-14 20:22 Kevin Ryde
2003-11-17 13:29 ` Juri Linkov
0 siblings, 1 reply; 1364+ messages in thread
From: Kevin Ryde @ 2003-11-14 20:22 UTC (permalink / raw
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-14 20:22 doc elisp intro cross reference fixes Kevin Ryde
@ 2003-11-17 13:29 ` Juri Linkov
2003-11-17 20:12 ` Robert J. Chassell
2003-11-18 20:48 ` Kevin Ryde
0 siblings, 2 replies; 1364+ messages in thread
From: Juri Linkov @ 2003-11-17 13:29 UTC (permalink / raw
Cc: emacs-devel
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-17 13:29 ` Juri Linkov
@ 2003-11-17 20:12 ` Robert J. Chassell
2003-11-18 15:34 ` Juri Linkov
2003-11-18 23:04 ` Richard Stallman
2003-11-18 20:48 ` Kevin Ryde
1 sibling, 2 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2003-11-17 20:12 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-17 20:12 ` Robert J. Chassell
@ 2003-11-18 15:34 ` Juri Linkov
2003-11-19 21:06 ` Robert J. Chassell
2003-11-18 23:04 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Juri Linkov @ 2003-11-18 15:34 UTC (permalink / raw
"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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-17 13:29 ` Juri Linkov
2003-11-17 20:12 ` Robert J. Chassell
@ 2003-11-18 20:48 ` Kevin Ryde
2003-11-18 21:31 ` Juri Linkov
1 sibling, 1 reply; 1364+ messages in thread
From: Kevin Ryde @ 2003-11-18 20:48 UTC (permalink / raw
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 :)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-18 20:48 ` Kevin Ryde
@ 2003-11-18 21:31 ` Juri Linkov
2003-11-20 21:42 ` Kevin Ryde
0 siblings, 1 reply; 1364+ messages in thread
From: Juri Linkov @ 2003-11-18 21:31 UTC (permalink / raw
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-17 20:12 ` Robert J. Chassell
2003-11-18 15:34 ` Juri Linkov
@ 2003-11-18 23:04 ` Richard Stallman
2003-11-19 3:08 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-11-18 23:04 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-18 23:04 ` Richard Stallman
@ 2003-11-19 3:08 ` Stefan Monnier
2003-11-19 4:18 ` Luc Teirlinck
2003-11-26 18:03 ` Per Abrahamsen
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-19 3:08 UTC (permalink / raw
Cc: bob, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 3:08 ` Stefan Monnier
@ 2003-11-19 4:18 ` Luc Teirlinck
2003-11-19 4:29 ` Stefan Monnier
2003-11-26 18:03 ` Per Abrahamsen
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-19 4:18 UTC (permalink / raw
Cc: bob, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 4:18 ` Luc Teirlinck
@ 2003-11-19 4:29 ` Stefan Monnier
2003-11-19 5:05 ` Luc Teirlinck
2003-11-19 5:28 ` Luc Teirlinck
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-19 4:29 UTC (permalink / raw
Cc: bob, rms, emacs-devel
> - 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 4:29 ` Stefan Monnier
@ 2003-11-19 5:05 ` Luc Teirlinck
2003-11-19 13:53 ` Stefan Monnier
2003-11-19 5:28 ` Luc Teirlinck
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-19 5:05 UTC (permalink / raw
Cc: bob, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 4:29 ` Stefan Monnier
2003-11-19 5:05 ` Luc Teirlinck
@ 2003-11-19 5:28 ` Luc Teirlinck
2003-11-19 13:56 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-19 5:28 UTC (permalink / raw
Cc: bob, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 5:05 ` Luc Teirlinck
@ 2003-11-19 13:53 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-19 13:53 UTC (permalink / raw
Cc: bob, rms, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 5:28 ` Luc Teirlinck
@ 2003-11-19 13:56 ` Stefan Monnier
2003-11-19 20:23 ` Kevin Rodgers
2003-11-20 4:06 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-19 13:56 UTC (permalink / raw
Cc: bob, rms, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 13:56 ` Stefan Monnier
@ 2003-11-19 20:23 ` Kevin Rodgers
2003-11-19 21:15 ` Stefan Monnier
2003-11-20 4:06 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Kevin Rodgers @ 2003-11-19 20:23 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-18 15:34 ` Juri Linkov
@ 2003-11-19 21:06 ` Robert J. Chassell
0 siblings, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2003-11-19 21:06 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 20:23 ` Kevin Rodgers
@ 2003-11-19 21:15 ` Stefan Monnier
2003-11-19 22:38 ` Luc Teirlinck
` (3 more replies)
0 siblings, 4 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-19 21:15 UTC (permalink / raw
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 21:15 ` Stefan Monnier
@ 2003-11-19 22:38 ` Luc Teirlinck
2003-11-20 4:53 ` Stefan Monnier
2003-11-19 23:48 ` Luc Teirlinck
` (2 subsequent siblings)
3 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-19 22:38 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 21:15 ` Stefan Monnier
2003-11-19 22:38 ` Luc Teirlinck
@ 2003-11-19 23:48 ` Luc Teirlinck
2003-11-19 23:56 ` Miles Bader
2003-11-20 4:58 ` Stefan Monnier
2003-11-20 20:13 ` Kevin Rodgers
2003-11-21 4:08 ` Richard Stallman
3 siblings, 2 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-19 23:48 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 23:48 ` Luc Teirlinck
@ 2003-11-19 23:56 ` Miles Bader
2003-11-20 20:18 ` Kevin Rodgers
2003-11-20 4:58 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2003-11-19 23:56 UTC (permalink / raw
Cc: ihs_4664, monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 13:56 ` Stefan Monnier
2003-11-19 20:23 ` Kevin Rodgers
@ 2003-11-20 4:06 ` Richard Stallman
2003-11-20 4:57 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-11-20 4:06 UTC (permalink / raw
Cc: bob, teirllm, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 22:38 ` Luc Teirlinck
@ 2003-11-20 4:53 ` Stefan Monnier
2003-11-20 13:13 ` David Kastrup
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 4:53 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 4:06 ` Richard Stallman
@ 2003-11-20 4:57 ` Stefan Monnier
2003-11-20 20:20 ` Kevin Rodgers
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 4:57 UTC (permalink / raw
Cc: bob, teirllm, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 23:48 ` Luc Teirlinck
2003-11-19 23:56 ` Miles Bader
@ 2003-11-20 4:58 ` Stefan Monnier
2003-11-20 5:12 ` Luc Teirlinck
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 4:58 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 4:58 ` Stefan Monnier
@ 2003-11-20 5:12 ` Luc Teirlinck
2003-11-20 14:39 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-20 5:12 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 4:53 ` Stefan Monnier
@ 2003-11-20 13:13 ` David Kastrup
2003-11-20 14:35 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: David Kastrup @ 2003-11-20 13:13 UTC (permalink / raw
Cc: ihs_4664, Luc Teirlinck, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 13:13 ` David Kastrup
@ 2003-11-20 14:35 ` Stefan Monnier
2003-11-20 14:47 ` David Kastrup
2003-11-20 14:51 ` David Kastrup
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 14:35 UTC (permalink / raw
Cc: ihs_4664, Luc Teirlinck, emacs-devel
>> > 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 5:12 ` Luc Teirlinck
@ 2003-11-20 14:39 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 14:39 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 14:35 ` Stefan Monnier
@ 2003-11-20 14:47 ` David Kastrup
2003-11-20 15:43 ` Stefan Monnier
2003-11-20 20:21 ` Kevin Rodgers
2003-11-20 14:51 ` David Kastrup
1 sibling, 2 replies; 1364+ messages in thread
From: David Kastrup @ 2003-11-20 14:47 UTC (permalink / raw
Cc: Luc Teirlinck, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 14:35 ` Stefan Monnier
2003-11-20 14:47 ` David Kastrup
@ 2003-11-20 14:51 ` David Kastrup
2003-11-20 15:46 ` Stefan Monnier
2003-11-20 20:33 ` Kevin Rodgers
1 sibling, 2 replies; 1364+ messages in thread
From: David Kastrup @ 2003-11-20 14:51 UTC (permalink / raw
Cc: ihs_4664, Luc Teirlinck, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 14:47 ` David Kastrup
@ 2003-11-20 15:43 ` Stefan Monnier
2003-11-20 20:21 ` Kevin Rodgers
1 sibling, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 15:43 UTC (permalink / raw
Cc: Luc Teirlinck, emacs-devel
>> >> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 14:51 ` David Kastrup
@ 2003-11-20 15:46 ` Stefan Monnier
2003-11-20 20:33 ` Kevin Rodgers
1 sibling, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 15:46 UTC (permalink / raw
Cc: ihs_4664, Luc Teirlinck, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 21:15 ` Stefan Monnier
2003-11-19 22:38 ` Luc Teirlinck
2003-11-19 23:48 ` Luc Teirlinck
@ 2003-11-20 20:13 ` Kevin Rodgers
2003-11-20 22:35 ` Stefan Monnier
2003-11-29 21:25 ` Kai Grossjohann
2003-11-21 4:08 ` Richard Stallman
3 siblings, 2 replies; 1364+ messages in thread
From: Kevin Rodgers @ 2003-11-20 20:13 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 23:56 ` Miles Bader
@ 2003-11-20 20:18 ` Kevin Rodgers
0 siblings, 0 replies; 1364+ messages in thread
From: Kevin Rodgers @ 2003-11-20 20:18 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 4:57 ` Stefan Monnier
@ 2003-11-20 20:20 ` Kevin Rodgers
2003-11-20 22:36 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Kevin Rodgers @ 2003-11-20 20:20 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 14:47 ` David Kastrup
2003-11-20 15:43 ` Stefan Monnier
@ 2003-11-20 20:21 ` Kevin Rodgers
1 sibling, 0 replies; 1364+ messages in thread
From: Kevin Rodgers @ 2003-11-20 20:21 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 14:51 ` David Kastrup
2003-11-20 15:46 ` Stefan Monnier
@ 2003-11-20 20:33 ` Kevin Rodgers
2003-11-20 20:58 ` David Kastrup
2003-11-26 18:09 ` Per Abrahamsen
1 sibling, 2 replies; 1364+ messages in thread
From: Kevin Rodgers @ 2003-11-20 20:33 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 20:33 ` Kevin Rodgers
@ 2003-11-20 20:58 ` David Kastrup
2003-11-26 18:09 ` Per Abrahamsen
1 sibling, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2003-11-20 20:58 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-18 21:31 ` Juri Linkov
@ 2003-11-20 21:42 ` Kevin Ryde
0 siblings, 0 replies; 1364+ messages in thread
From: Kevin Ryde @ 2003-11-20 21:42 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 20:13 ` Kevin Rodgers
@ 2003-11-20 22:35 ` Stefan Monnier
2003-11-29 21:25 ` Kai Grossjohann
1 sibling, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 22:35 UTC (permalink / raw
Cc: emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 20:20 ` Kevin Rodgers
@ 2003-11-20 22:36 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-20 22:36 UTC (permalink / raw
Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 21:15 ` Stefan Monnier
` (2 preceding siblings ...)
2003-11-20 20:13 ` Kevin Rodgers
@ 2003-11-21 4:08 ` Richard Stallman
2003-11-21 4:28 ` Miles Bader
2003-11-21 15:03 ` Stefan Monnier
3 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-11-21 4:08 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-21 4:08 ` Richard Stallman
@ 2003-11-21 4:28 ` Miles Bader
2003-11-21 15:03 ` Stefan Monnier
1 sibling, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2003-11-21 4:28 UTC (permalink / raw
Cc: ihs_4664, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-21 4:08 ` Richard Stallman
2003-11-21 4:28 ` Miles Bader
@ 2003-11-21 15:03 ` Stefan Monnier
2003-11-23 16:34 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-21 15:03 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-21 15:03 ` Stefan Monnier
@ 2003-11-23 16:34 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-11-23 16:34 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-19 3:08 ` Stefan Monnier
2003-11-19 4:18 ` Luc Teirlinck
@ 2003-11-26 18:03 ` Per Abrahamsen
2003-11-26 18:55 ` Simon Josefsson
2003-11-27 7:28 ` Juri Linkov
1 sibling, 2 replies; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-26 18:03 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 20:33 ` Kevin Rodgers
2003-11-20 20:58 ` David Kastrup
@ 2003-11-26 18:09 ` Per Abrahamsen
2003-11-26 18:14 ` Stefan Monnier
2003-11-27 19:08 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-26 18:09 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 18:09 ` Per Abrahamsen
@ 2003-11-26 18:14 ` Stefan Monnier
2003-11-26 23:49 ` Luc Teirlinck
` (3 more replies)
2003-11-27 19:08 ` Richard Stallman
1 sibling, 4 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-26 18:14 UTC (permalink / raw
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 18:03 ` Per Abrahamsen
@ 2003-11-26 18:55 ` Simon Josefsson
2003-11-27 7:28 ` Juri Linkov
1 sibling, 0 replies; 1364+ messages in thread
From: Simon Josefsson @ 2003-11-26 18:55 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL, rmail-mbox-branch
2003-10-27 23:44 ` Richard Stallman
@ 2003-11-26 22:44 ` Alexander Pohoyda
0 siblings, 0 replies; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-11-26 22:44 UTC (permalink / raw
Cc: eliz, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 18:14 ` Stefan Monnier
@ 2003-11-26 23:49 ` Luc Teirlinck
2003-11-27 0:51 ` Stefan Monnier
` (2 more replies)
2003-11-26 23:58 ` Luc Teirlinck
` (2 subsequent siblings)
3 siblings, 3 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-26 23:49 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 18:14 ` Stefan Monnier
2003-11-26 23:49 ` Luc Teirlinck
@ 2003-11-26 23:58 ` Luc Teirlinck
2003-11-27 0:14 ` Luc Teirlinck
2003-11-27 11:03 ` Per Abrahamsen
3 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-26 23:58 UTC (permalink / raw
Cc: monnier, emacs-devel
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 18:14 ` Stefan Monnier
2003-11-26 23:49 ` Luc Teirlinck
2003-11-26 23:58 ` Luc Teirlinck
@ 2003-11-27 0:14 ` Luc Teirlinck
2003-11-27 11:26 ` Per Abrahamsen
2003-11-27 11:03 ` Per Abrahamsen
3 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-27 0:14 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 23:49 ` Luc Teirlinck
@ 2003-11-27 0:51 ` Stefan Monnier
2003-11-27 3:22 ` Luc Teirlinck
2003-11-27 3:45 ` Luc Teirlinck
2003-11-28 23:14 ` Richard Stallman
2003-11-28 23:15 ` Richard Stallman
2 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-27 0:51 UTC (permalink / raw
Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 0:51 ` Stefan Monnier
@ 2003-11-27 3:22 ` Luc Teirlinck
2003-11-27 3:45 ` Luc Teirlinck
1 sibling, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-27 3:22 UTC (permalink / raw
Cc: emacs-devel
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.
`
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 0:51 ` Stefan Monnier
2003-11-27 3:22 ` Luc Teirlinck
@ 2003-11-27 3:45 ` Luc Teirlinck
1 sibling, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-27 3:45 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 18:03 ` Per Abrahamsen
2003-11-26 18:55 ` Simon Josefsson
@ 2003-11-27 7:28 ` Juri Linkov
2003-11-27 11:10 ` Per Abrahamsen
[not found] ` <juri@jurta.org>
1 sibling, 2 replies; 1364+ messages in thread
From: Juri Linkov @ 2003-11-27 7:28 UTC (permalink / raw
Cc: emacs-devel
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 18:14 ` Stefan Monnier
` (2 preceding siblings ...)
2003-11-27 0:14 ` Luc Teirlinck
@ 2003-11-27 11:03 ` Per Abrahamsen
3 siblings, 0 replies; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-27 11:03 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 7:28 ` Juri Linkov
@ 2003-11-27 11:10 ` Per Abrahamsen
2003-11-28 23:14 ` Richard Stallman
[not found] ` <juri@jurta.org>
1 sibling, 1 reply; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-27 11:10 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 0:14 ` Luc Teirlinck
@ 2003-11-27 11:26 ` Per Abrahamsen
2003-11-27 16:11 ` Luc Teirlinck
0 siblings, 1 reply; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-27 11:26 UTC (permalink / raw
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))))))
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 11:26 ` Per Abrahamsen
@ 2003-11-27 16:11 ` Luc Teirlinck
2003-11-27 16:48 ` Luc Teirlinck
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-27 16:11 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 16:11 ` Luc Teirlinck
@ 2003-11-27 16:48 ` Luc Teirlinck
2003-11-27 18:46 ` Per Abrahamsen
2003-11-28 23:14 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-27 16:48 UTC (permalink / raw
Cc: abraham, emacs-devel
>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>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 16:11 ` Luc Teirlinck
2003-11-27 16:48 ` Luc Teirlinck
@ 2003-11-27 18:46 ` Per Abrahamsen
[not found] ` <200311271857.hARIvGr04327@raven.dms.auburn.edu>
2003-11-28 23:14 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-27 18:46 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 18:09 ` Per Abrahamsen
2003-11-26 18:14 ` Stefan Monnier
@ 2003-11-27 19:08 ` Richard Stallman
2003-11-28 10:45 ` Per Abrahamsen
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-11-27 19:08 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
[not found] ` <200311271857.hARIvGr04327@raven.dms.auburn.edu>
@ 2003-11-27 19:09 ` Per Abrahamsen
[not found] ` <200311271946.hARJkhd04426@raven.dms.auburn.edu>
0 siblings, 1 reply; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-27 19:09 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
[not found] ` <juri@jurta.org>
@ 2003-11-28 1:47 ` Peter S Galbraith
0 siblings, 0 replies; 1364+ messages in thread
From: Peter S Galbraith @ 2003-11-28 1:47 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 19:08 ` Richard Stallman
@ 2003-11-28 10:45 ` Per Abrahamsen
0 siblings, 0 replies; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-28 10:45 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
[not found] ` <200311272115.hARLFFo04571@raven.dms.auburn.edu>
@ 2003-11-28 11:41 ` Per Abrahamsen
[not found] ` <200311281810.hASIACS06152@raven.dms.auburn.edu>
0 siblings, 1 reply; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-28 11:41 UTC (permalink / raw
Cc: monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 11:10 ` Per Abrahamsen
@ 2003-11-28 23:14 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-11-28 23:14 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-27 16:11 ` Luc Teirlinck
2003-11-27 16:48 ` Luc Teirlinck
2003-11-27 18:46 ` Per Abrahamsen
@ 2003-11-28 23:14 ` Richard Stallman
2003-11-29 14:04 ` Per Abrahamsen
2 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-11-28 23:14 UTC (permalink / raw
Cc: abraham, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 23:49 ` Luc Teirlinck
2003-11-27 0:51 ` Stefan Monnier
@ 2003-11-28 23:14 ` Richard Stallman
2003-11-29 20:29 ` Luc Teirlinck
2003-11-28 23:15 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2003-11-28 23:14 UTC (permalink / raw
Cc: monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-26 23:49 ` Luc Teirlinck
2003-11-27 0:51 ` Stefan Monnier
2003-11-28 23:14 ` Richard Stallman
@ 2003-11-28 23:15 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-11-28 23:15 UTC (permalink / raw
Cc: monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-28 23:14 ` Richard Stallman
@ 2003-11-29 14:04 ` Per Abrahamsen
[not found] ` <200311291445.hATEjN408572@raven.dms.auburn.edu>
[not found] ` <E1AQd7O-0002KQ-Bb@fencepost.gnu.org>
0 siblings, 2 replies; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-29 14:04 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
[not found] ` <x5fzg8p873.fsf@lola.goethe.zz>
@ 2003-11-29 15:40 ` Per Abrahamsen
0 siblings, 0 replies; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-29 15:40 UTC (permalink / raw
Cc: Luc Teirlinck, monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
[not found] ` <200311291445.hATEjN408572@raven.dms.auburn.edu>
@ 2003-11-29 16:54 ` Per Abrahamsen
[not found] ` <200311291828.hATISht08904@raven.dms.auburn.edu>
0 siblings, 1 reply; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-29 16:54 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-28 23:14 ` Richard Stallman
@ 2003-11-29 20:29 ` Luc Teirlinck
0 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-29 20:29 UTC (permalink / raw
Cc: monnier, emacs-devel
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>
============================================================
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-20 20:13 ` Kevin Rodgers
2003-11-20 22:35 ` Stefan Monnier
@ 2003-11-29 21:25 ` Kai Grossjohann
2003-11-30 19:51 ` Stefan Monnier
2003-12-01 1:45 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Kai Grossjohann @ 2003-11-29 21:25 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
[not found] ` <200311291828.hATISht08904@raven.dms.auburn.edu>
@ 2003-11-30 13:06 ` Per Abrahamsen
2003-11-30 15:19 ` Luc Teirlinck
0 siblings, 1 reply; 1364+ messages in thread
From: Per Abrahamsen @ 2003-11-30 13:06 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-30 13:06 ` Per Abrahamsen
@ 2003-11-30 15:19 ` Luc Teirlinck
0 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2003-11-30 15:19 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-29 21:25 ` Kai Grossjohann
@ 2003-11-30 19:51 ` Stefan Monnier
2003-11-30 20:31 ` Kai Grossjohann
2003-12-01 1:45 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-30 19:51 UTC (permalink / raw
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-30 19:51 ` Stefan Monnier
@ 2003-11-30 20:31 ` Kai Grossjohann
2003-11-30 21:08 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Grossjohann @ 2003-11-30 20:31 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-30 20:31 ` Kai Grossjohann
@ 2003-11-30 21:08 ` Stefan Monnier
2003-12-01 21:14 ` Kai Grossjohann
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-11-30 21:08 UTC (permalink / raw
Cc: emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-29 21:25 ` Kai Grossjohann
2003-11-30 19:51 ` Stefan Monnier
@ 2003-12-01 1:45 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-12-01 1:45 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
[not found] ` <E1AQd7O-0002KQ-Bb@fencepost.gnu.org>
@ 2003-12-01 11:06 ` Per Abrahamsen
2003-12-02 4:17 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Per Abrahamsen @ 2003-12-01 11:06 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-11-30 21:08 ` Stefan Monnier
@ 2003-12-01 21:14 ` Kai Grossjohann
2003-12-02 16:17 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Kai Grossjohann @ 2003-12-01 21:14 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-12-01 11:06 ` Per Abrahamsen
@ 2003-12-02 4:17 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-12-02 4:17 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-12-01 21:14 ` Kai Grossjohann
@ 2003-12-02 16:17 ` Stefan Monnier
2003-12-03 4:45 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2003-12-02 16:17 UTC (permalink / raw
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: doc elisp intro cross reference fixes
2003-12-02 16:17 ` Stefan Monnier
@ 2003-12-03 4:45 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-12-03 4:45 UTC (permalink / raw
Cc: kai, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Merging quoted-printable functions
2003-10-20 23:20 ` Richard Stallman
@ 2003-12-26 17:40 ` Alexander Pohoyda
2003-12-27 22:16 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Alexander Pohoyda @ 2003-12-26 17:40 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Merging quoted-printable functions
2003-12-26 17:40 ` Merging quoted-printable functions Alexander Pohoyda
@ 2003-12-27 22:16 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2003-12-27 22:16 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* invalid-regexp in calendar
@ 2004-01-16 18:56 ` Sam Steingold
2004-01-17 13:49 ` Thien-Thi Nguyen
2004-02-05 2:52 ` Ed Reingold
0 siblings, 2 replies; 1364+ messages in thread
From: Sam Steingold @ 2004-01-16 18:56 UTC (permalink / raw
Cc: deego
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: invalid-regexp in calendar
2004-01-16 18:56 ` invalid-regexp in calendar Sam Steingold
@ 2004-01-17 13:49 ` Thien-Thi Nguyen
2004-02-05 2:52 ` Ed Reingold
1 sibling, 0 replies; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2004-01-17 13:49 UTC (permalink / raw
Cc: deego
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: invalid-regexp in calendar
2004-01-16 18:56 ` invalid-regexp in calendar Sam Steingold
2004-01-17 13:49 ` Thien-Thi Nguyen
@ 2004-02-05 2:52 ` Ed Reingold
2004-02-05 20:11 ` D. Goel
1 sibling, 1 reply; 1364+ messages in thread
From: Ed Reingold @ 2004-02-05 2:52 UTC (permalink / raw
Cc: deego, emacs-devel
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
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: invalid-regexp in calendar
2004-02-05 2:52 ` Ed Reingold
@ 2004-02-05 20:11 ` D. Goel
0 siblings, 0 replies; 1364+ messages in thread
From: D. Goel @ 2004-02-05 20:11 UTC (permalink / raw
Cc: sds, emacs-devel
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 :)
[...]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* dired alignment
@ 2004-05-04 18:28 Karl Eichwalder
2004-05-04 21:32 ` Andreas Schwab
0 siblings, 1 reply; 1364+ messages in thread
From: Karl Eichwalder @ 2004-05-04 18:28 UTC (permalink / raw
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-04 18:28 dired alignment Karl Eichwalder
@ 2004-05-04 21:32 ` Andreas Schwab
2004-05-05 20:20 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Andreas Schwab @ 2004-05-04 21:32 UTC (permalink / raw
Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS)
@ 2004-05-04 22:27 Peter Whaite
2004-05-04 22:51 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2004-05-04 22:27 UTC (permalink / raw
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS)
2004-05-04 22:27 Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS) Peter Whaite
@ 2004-05-04 22:51 ` Miles Bader
2004-05-04 23:21 ` Peter Whaite
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2004-05-04 22:51 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS)
2004-05-04 22:51 ` Miles Bader
@ 2004-05-04 23:21 ` Peter Whaite
2004-05-04 23:50 ` David Kastrup
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2004-05-04 23:21 UTC (permalink / raw
Cc: Peter Whaite, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS)
2004-05-04 23:21 ` Peter Whaite
@ 2004-05-04 23:50 ` David Kastrup
0 siblings, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2004-05-04 23:50 UTC (permalink / raw
Cc: emacs-devel, Miles Bader
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Mode-line customization.
@ 2004-05-05 7:16 Matt Hodges
2004-05-05 15:04 ` Chris Green
2004-05-06 0:17 ` Masatake YAMATO
0 siblings, 2 replies; 1364+ messages in thread
From: Matt Hodges @ 2004-05-05 7:16 UTC (permalink / raw
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-05 7:16 Mode-line customization Matt Hodges
@ 2004-05-05 15:04 ` Chris Green
2004-05-05 21:19 ` Juanma Barranquero
2004-05-06 9:22 ` Richard Stallman
2004-05-06 0:17 ` Masatake YAMATO
1 sibling, 2 replies; 1364+ messages in thread
From: Chris Green @ 2004-05-05 15:04 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-04 21:32 ` Andreas Schwab
@ 2004-05-05 20:20 ` Richard Stallman
2004-05-05 21:12 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2004-05-05 20:20 UTC (permalink / raw
Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-05 20:20 ` Richard Stallman
@ 2004-05-05 21:12 ` Stefan Monnier
2004-05-07 0:28 ` Richard Stallman
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Stefan Monnier @ 2004-05-05 21:12 UTC (permalink / raw
Cc: Andreas Schwab, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-05 15:04 ` Chris Green
@ 2004-05-05 21:19 ` Juanma Barranquero
2004-05-06 9:22 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Juanma Barranquero @ 2004-05-05 21:19 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-05 7:16 Mode-line customization Matt Hodges
2004-05-05 15:04 ` Chris Green
@ 2004-05-06 0:17 ` Masatake YAMATO
1 sibling, 0 replies; 1364+ messages in thread
From: Masatake YAMATO @ 2004-05-06 0:17 UTC (permalink / raw
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-05 15:04 ` Chris Green
2004-05-05 21:19 ` Juanma Barranquero
@ 2004-05-06 9:22 ` Richard Stallman
2004-05-06 9:40 ` Miles Bader
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2004-05-06 9:22 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 9:22 ` Richard Stallman
@ 2004-05-06 9:40 ` Miles Bader
2004-05-06 10:00 ` David Kastrup
2004-05-06 14:59 ` Stefan Monnier
0 siblings, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2004-05-06 9:40 UTC (permalink / raw
Cc: Chris Green, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 9:40 ` Miles Bader
@ 2004-05-06 10:00 ` David Kastrup
2004-05-06 10:44 ` Miles Bader
2004-05-06 14:59 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: David Kastrup @ 2004-05-06 10:00 UTC (permalink / raw
Cc: rms, Chris Green, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 10:00 ` David Kastrup
@ 2004-05-06 10:44 ` Miles Bader
2004-05-06 11:59 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2004-05-06 10:44 UTC (permalink / raw
Cc: rms, Chris Green, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 10:44 ` Miles Bader
@ 2004-05-06 11:59 ` Kim F. Storm
2004-05-06 14:06 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Kim F. Storm @ 2004-05-06 11:59 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 11:59 ` Kim F. Storm
@ 2004-05-06 14:06 ` Miles Bader
2004-05-06 14:43 ` David Kastrup
2004-05-06 15:38 ` David Kastrup
2004-05-08 1:20 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2004-05-06 14:06 UTC (permalink / raw
Cc: emacs-devel, 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 14:06 ` Miles Bader
@ 2004-05-06 14:43 ` David Kastrup
2004-05-07 1:49 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: David Kastrup @ 2004-05-06 14:43 UTC (permalink / raw
Cc: emacs-devel, Kim F. Storm
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 9:40 ` Miles Bader
2004-05-06 10:00 ` David Kastrup
@ 2004-05-06 14:59 ` Stefan Monnier
2004-05-06 17:38 ` Peter Whaite
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2004-05-06 14:59 UTC (permalink / raw
Cc: rms, Chris Green, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 11:59 ` Kim F. Storm
2004-05-06 14:06 ` Miles Bader
@ 2004-05-06 15:38 ` David Kastrup
2004-05-08 1:20 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2004-05-06 15:38 UTC (permalink / raw
Cc: emacs-devel, Miles Bader
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 14:59 ` Stefan Monnier
@ 2004-05-06 17:38 ` Peter Whaite
2004-05-11 12:50 ` Chris Green
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2004-05-06 17:38 UTC (permalink / raw
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-05 21:12 ` Stefan Monnier
@ 2004-05-07 0:28 ` Richard Stallman
2004-05-07 14:55 ` Peter Whaite
2004-05-07 16:32 ` Edward O'Connor
2 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2004-05-07 0:28 UTC (permalink / raw
Cc: schwab, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 14:43 ` David Kastrup
@ 2004-05-07 1:49 ` Miles Bader
2004-05-07 7:47 ` David Kastrup
2004-05-08 21:59 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Miles Bader @ 2004-05-07 1:49 UTC (permalink / raw
Cc: emacs-devel, Kim F. Storm
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"]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-07 1:49 ` Miles Bader
@ 2004-05-07 7:47 ` David Kastrup
2004-05-07 17:02 ` Kevin Rodgers
2004-05-08 21:59 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: David Kastrup @ 2004-05-07 7:47 UTC (permalink / raw
Cc: Kim F. Storm, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-05 21:12 ` Stefan Monnier
2004-05-07 0:28 ` Richard Stallman
@ 2004-05-07 14:55 ` Peter Whaite
2004-05-08 21:59 ` Richard Stallman
2004-05-07 16:32 ` Edward O'Connor
2 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2004-05-07 14:55 UTC (permalink / raw
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-05 21:12 ` Stefan Monnier
2004-05-07 0:28 ` Richard Stallman
2004-05-07 14:55 ` Peter Whaite
@ 2004-05-07 16:32 ` Edward O'Connor
2 siblings, 0 replies; 1364+ messages in thread
From: Edward O'Connor @ 2004-05-07 16:32 UTC (permalink / raw
>> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-07 7:47 ` David Kastrup
@ 2004-05-07 17:02 ` Kevin Rodgers
2004-05-07 18:14 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Kevin Rodgers @ 2004-05-07 17:02 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-07 17:02 ` Kevin Rodgers
@ 2004-05-07 18:14 ` Stefan Monnier
0 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2004-05-07 18:14 UTC (permalink / raw
Cc: emacs-devel
> (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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 11:59 ` Kim F. Storm
2004-05-06 14:06 ` Miles Bader
2004-05-06 15:38 ` David Kastrup
@ 2004-05-08 1:20 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2004-05-08 1:20 UTC (permalink / raw
Cc: emacs-devel, miles
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-07 14:55 ` Peter Whaite
@ 2004-05-08 21:59 ` Richard Stallman
2004-05-12 15:49 ` Peter Whaite
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2004-05-08 21:59 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-07 1:49 ` Miles Bader
2004-05-07 7:47 ` David Kastrup
@ 2004-05-08 21:59 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2004-05-08 21:59 UTC (permalink / raw
Cc: dak, storm, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Mode-line customization.
2004-05-06 17:38 ` Peter Whaite
@ 2004-05-11 12:50 ` Chris Green
0 siblings, 0 replies; 1364+ messages in thread
From: Chris Green @ 2004-05-11 12:50 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-08 21:59 ` Richard Stallman
@ 2004-05-12 15:49 ` Peter Whaite
2004-05-12 17:01 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2004-05-12 15:49 UTC (permalink / raw
Cc: rms
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-12 15:49 ` Peter Whaite
@ 2004-05-12 17:01 ` Stefan Monnier
2004-05-13 15:46 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2004-05-12 17:01 UTC (permalink / raw
Cc: rms, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-12 17:01 ` Stefan Monnier
@ 2004-05-13 15:46 ` Richard Stallman
2004-05-13 16:43 ` Andreas Schwab
2004-05-13 19:34 ` Miles Bader
0 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2004-05-13 15:46 UTC (permalink / raw
Cc: emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-13 15:46 ` Richard Stallman
@ 2004-05-13 16:43 ` Andreas Schwab
2004-05-14 21:01 ` Richard Stallman
2004-05-13 19:34 ` Miles Bader
1 sibling, 1 reply; 1364+ messages in thread
From: Andreas Schwab @ 2004-05-13 16:43 UTC (permalink / raw
Cc: Stefan Monnier, emacs, emacs-devel
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-13 15:46 ` Richard Stallman
2004-05-13 16:43 ` Andreas Schwab
@ 2004-05-13 19:34 ` Miles Bader
2004-05-14 21:02 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Miles Bader @ 2004-05-13 19:34 UTC (permalink / raw
Cc: Stefan Monnier, emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-13 16:43 ` Andreas Schwab
@ 2004-05-14 21:01 ` Richard Stallman
2004-05-14 22:16 ` Andreas Schwab
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2004-05-14 21:01 UTC (permalink / raw
Cc: monnier, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-13 19:34 ` Miles Bader
@ 2004-05-14 21:02 ` Richard Stallman
2004-05-14 23:32 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2004-05-14 21:02 UTC (permalink / raw
Cc: monnier, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-14 21:01 ` Richard Stallman
@ 2004-05-14 22:16 ` Andreas Schwab
0 siblings, 0 replies; 1364+ messages in thread
From: Andreas Schwab @ 2004-05-14 22:16 UTC (permalink / raw
Cc: monnier, emacs, emacs-devel
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: dired alignment
2004-05-14 21:02 ` Richard Stallman
@ 2004-05-14 23:32 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2004-05-14 23:32 UTC (permalink / raw
Cc: emacs-devel, monnier, emacs, 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]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* $HOME default on w32
@ 2004-10-25 12:04 Stefan
2004-10-25 15:06 ` Lennart Borgman
2004-10-25 19:12 ` Jason Rumney
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan @ 2004-10-25 12:04 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-25 12:04 $HOME default on w32 Stefan
@ 2004-10-25 15:06 ` Lennart Borgman
2004-10-25 16:31 ` CHENG Gao
2004-10-25 18:04 ` Guy Gascoigne - Piggford
2004-10-25 19:12 ` Jason Rumney
1 sibling, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2004-10-25 15:06 UTC (permalink / raw
Cc: Emacs Devel
----- 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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-25 15:06 ` Lennart Borgman
@ 2004-10-25 16:31 ` CHENG Gao
2004-10-25 17:34 ` Stefan Monnier
` (2 more replies)
2004-10-25 18:04 ` Guy Gascoigne - Piggford
1 sibling, 3 replies; 1364+ messages in thread
From: CHENG Gao @ 2004-10-25 16:31 UTC (permalink / raw
,----
| 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.
--
这去者,不能见他的脸,背影模糊。
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-25 16:31 ` CHENG Gao
@ 2004-10-25 17:34 ` Stefan Monnier
2004-10-25 18:41 ` Stefan Daschek
2004-10-26 7:32 ` Kai Grossjohann
2 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2004-10-25 17:34 UTC (permalink / raw
Cc: emacs-devel
> ,----
> | 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-25 15:06 ` Lennart Borgman
2004-10-25 16:31 ` CHENG Gao
@ 2004-10-25 18:04 ` Guy Gascoigne - Piggford
1 sibling, 0 replies; 1364+ messages in thread
From: Guy Gascoigne - Piggford @ 2004-10-25 18:04 UTC (permalink / raw
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
>
>
>
>
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-25 16:31 ` CHENG Gao
2004-10-25 17:34 ` Stefan Monnier
@ 2004-10-25 18:41 ` Stefan Daschek
2004-10-26 7:32 ` Kai Grossjohann
2 siblings, 0 replies; 1364+ messages in thread
From: Stefan Daschek @ 2004-10-25 18:41 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-25 12:04 $HOME default on w32 Stefan
2004-10-25 15:06 ` Lennart Borgman
@ 2004-10-25 19:12 ` Jason Rumney
2004-10-25 20:24 ` Lennart Borgman
1 sibling, 1 reply; 1364+ messages in thread
From: Jason Rumney @ 2004-10-25 19:12 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-25 19:12 ` Jason Rumney
@ 2004-10-25 20:24 ` Lennart Borgman
0 siblings, 0 replies; 1364+ messages in thread
From: Lennart Borgman @ 2004-10-25 20:24 UTC (permalink / raw
Cc: emacs-devel
----- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-25 16:31 ` CHENG Gao
2004-10-25 17:34 ` Stefan Monnier
2004-10-25 18:41 ` Stefan Daschek
@ 2004-10-26 7:32 ` Kai Grossjohann
2004-10-26 16:32 ` Stefan Monnier
2 siblings, 1 reply; 1364+ messages in thread
From: Kai Grossjohann @ 2004-10-26 7:32 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-26 7:32 ` Kai Grossjohann
@ 2004-10-26 16:32 ` Stefan Monnier
2004-10-27 2:40 ` Jay Finger
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2004-10-26 16:32 UTC (permalink / raw
Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: $HOME default on w32
2004-10-26 16:32 ` Stefan Monnier
@ 2004-10-27 2:40 ` Jay Finger
2004-10-27 3:13 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Jay Finger @ 2004-10-27 2:40 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 2:40 ` Jay Finger
@ 2004-10-27 3:13 ` Stefan Monnier
2004-10-27 6:19 ` Stephan Stahl
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2004-10-27 3:13 UTC (permalink / raw
Cc: 'Kai Grossjohann', emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 3:13 ` Stefan Monnier
@ 2004-10-27 6:19 ` Stephan Stahl
2004-10-27 6:58 ` Cheng Gao
2004-10-27 12:58 ` Stefan Monnier
0 siblings, 2 replies; 1364+ messages in thread
From: Stephan Stahl @ 2004-10-27 6:19 UTC (permalink / raw
Cc: 'Kai Grossjohann', Jay Finger, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 6:19 ` Stephan Stahl
@ 2004-10-27 6:58 ` Cheng Gao
2004-10-27 8:50 ` Lennart Borgman
2004-10-27 12:58 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Cheng Gao @ 2004-10-27 6:58 UTC (permalink / raw
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.
--
相濡以沫,不如相忘于江湖。
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 6:58 ` Cheng Gao
@ 2004-10-27 8:50 ` Lennart Borgman
0 siblings, 0 replies; 1364+ messages in thread
From: Lennart Borgman @ 2004-10-27 8:50 UTC (permalink / raw
----- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 6:19 ` Stephan Stahl
2004-10-27 6:58 ` Cheng Gao
@ 2004-10-27 12:58 ` Stefan Monnier
2004-10-27 17:14 ` Jay Finger
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2004-10-27 12:58 UTC (permalink / raw
Cc: 'Kai Grossjohann', Jay Finger, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: $HOME default on w32
2004-10-27 12:58 ` Stefan Monnier
@ 2004-10-27 17:14 ` Jay Finger
2004-10-27 17:37 ` Lennart Borgman
2004-10-27 17:53 ` Stefan Monnier
0 siblings, 2 replies; 1364+ messages in thread
From: Jay Finger @ 2004-10-27 17:14 UTC (permalink / raw
Cc: ''Kai Grossjohann' ', emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 17:14 ` Jay Finger
@ 2004-10-27 17:37 ` Lennart Borgman
2004-10-28 5:24 ` Jay Finger
2004-10-27 17:53 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2004-10-27 17:37 UTC (permalink / raw
Cc: ''Kai Grossjohann' ', emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 17:14 ` Jay Finger
2004-10-27 17:37 ` Lennart Borgman
@ 2004-10-27 17:53 ` Stefan Monnier
2004-10-27 20:49 ` Peter Whaite
2004-10-28 5:45 ` Jay Finger
1 sibling, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2004-10-27 17:53 UTC (permalink / raw
Cc: 'Stephan Stahl', ''Kai Grossjohann' ',
emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 17:53 ` Stefan Monnier
@ 2004-10-27 20:49 ` Peter Whaite
2004-10-27 21:31 ` Adrian Aichner
2004-10-28 5:45 ` Jay Finger
1 sibling, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2004-10-27 20:49 UTC (permalink / raw
> > 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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: $HOME default on w32
2004-10-27 20:49 ` Peter Whaite
@ 2004-10-27 21:31 ` Adrian Aichner
0 siblings, 0 replies; 1364+ messages in thread
From: Adrian Aichner @ 2004-10-27 21:31 UTC (permalink / raw
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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: $HOME default on w32
2004-10-27 17:37 ` Lennart Borgman
@ 2004-10-28 5:24 ` Jay Finger
0 siblings, 0 replies; 1364+ messages in thread
From: Jay Finger @ 2004-10-28 5:24 UTC (permalink / raw
Cc: ''Kai Grossjohann' ', emacs-devel
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.
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: $HOME default on w32
2004-10-27 17:53 ` Stefan Monnier
2004-10-27 20:49 ` Peter Whaite
@ 2004-10-28 5:45 ` Jay Finger
1 sibling, 0 replies; 1364+ messages in thread
From: Jay Finger @ 2004-10-28 5:45 UTC (permalink / raw
Cc: 'Stephan Stahl', ''Kai Grossjohann' ',
emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* calendar problems
@ 2005-03-10 21:40 Karl Chen
2005-03-10 23:06 ` Alan Shutko
0 siblings, 1 reply; 1364+ messages in thread
From: Karl Chen @ 2005-03-10 21:40 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: calendar problems
2005-03-10 21:40 calendar problems Karl Chen
@ 2005-03-10 23:06 ` Alan Shutko
2005-03-11 1:32 ` Ed Reingold
0 siblings, 1 reply; 1364+ messages in thread
From: Alan Shutko @ 2005-03-10 23:06 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: calendar problems
2005-03-10 23:06 ` Alan Shutko
@ 2005-03-11 1:32 ` Ed Reingold
2005-03-11 17:01 ` Alan Shutko
2005-03-12 0:56 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Ed Reingold @ 2005-03-11 1:32 UTC (permalink / raw
Cc: emacs-devel
> > 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: calendar problems
2005-03-11 1:32 ` Ed Reingold
@ 2005-03-11 17:01 ` Alan Shutko
2005-03-12 0:56 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Alan Shutko @ 2005-03-11 17:01 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: calendar problems
2005-03-11 1:32 ` Ed Reingold
2005-03-11 17:01 ` Alan Shutko
@ 2005-03-12 0:56 ` Richard Stallman
2005-03-13 0:40 ` Ed Reingold
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-03-12 0:56 UTC (permalink / raw
Cc: ats, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: calendar problems
2005-03-12 0:56 ` Richard Stallman
@ 2005-03-13 0:40 ` Ed Reingold
2005-03-14 3:00 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Ed Reingold @ 2005-03-13 0:40 UTC (permalink / raw
Cc: ats, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: calendar problems
2005-03-13 0:40 ` Ed Reingold
@ 2005-03-14 3:00 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-03-14 3:00 UTC (permalink / raw
Cc: ats, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RMAIL slows
@ 2005-03-19 21:22 Robert J. Chassell
2005-03-19 22:04 ` David Kastrup
2005-03-20 12:59 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-03-19 21:22 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-19 21:22 RMAIL slows Robert J. Chassell
@ 2005-03-19 22:04 ` David Kastrup
2005-03-20 12:59 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2005-03-19 22:04 UTC (permalink / raw
Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-19 21:22 RMAIL slows Robert J. Chassell
2005-03-19 22:04 ` David Kastrup
@ 2005-03-20 12:59 ` Richard Stallman
2005-03-21 17:44 ` Robert J. Chassell
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-03-20 12:59 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-20 12:59 ` Richard Stallman
@ 2005-03-21 17:44 ` Robert J. Chassell
2005-03-22 13:56 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-03-21 17:44 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-21 17:44 ` Robert J. Chassell
@ 2005-03-22 13:56 ` Richard Stallman
2005-03-22 15:42 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-03-22 13:56 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-22 13:56 ` Richard Stallman
@ 2005-03-22 15:42 ` Robert J. Chassell
2005-03-22 18:55 ` Stefan Monnier
2005-03-23 0:59 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-03-22 15:42 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-22 15:42 ` Robert J. Chassell
@ 2005-03-22 18:55 ` Stefan Monnier
2005-03-23 0:59 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2005-03-22 18:55 UTC (permalink / raw
Cc: rms, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-22 15:42 ` Robert J. Chassell
2005-03-22 18:55 ` Stefan Monnier
@ 2005-03-23 0:59 ` Richard Stallman
2005-03-23 14:50 ` Robert J. Chassell
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-03-23 0:59 UTC (permalink / raw
Cc: emacs-devel
#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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-23 0:59 ` Richard Stallman
@ 2005-03-23 14:50 ` Robert J. Chassell
2005-03-24 5:19 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-03-23 14:50 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-23 14:50 ` Robert J. Chassell
@ 2005-03-24 5:19 ` Richard Stallman
2005-03-29 12:18 ` Robert J. Chassell
2005-04-08 19:40 ` Robert J. Chassell
0 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-03-24 5:19 UTC (permalink / raw
Cc: emacs-devel
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_...
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-24 5:19 ` Richard Stallman
@ 2005-03-29 12:18 ` Robert J. Chassell
2005-04-08 19:40 ` Robert J. Chassell
1 sibling, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-03-29 12:18 UTC (permalink / raw
(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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-03-24 5:19 ` Richard Stallman
2005-03-29 12:18 ` Robert J. Chassell
@ 2005-04-08 19:40 ` Robert J. Chassell
2005-04-08 22:57 ` Stefan Monnier
1 sibling, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-04-08 19:40 UTC (permalink / raw
... , 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-08 19:40 ` Robert J. Chassell
@ 2005-04-08 22:57 ` Stefan Monnier
2005-04-08 23:53 ` Kim F. Storm
2005-04-12 17:49 ` Robert J. Chassell
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2005-04-08 22:57 UTC (permalink / raw
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-08 22:57 ` Stefan Monnier
@ 2005-04-08 23:53 ` Kim F. Storm
2005-04-12 17:49 ` Robert J. Chassell
1 sibling, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2005-04-08 23:53 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-08 22:57 ` Stefan Monnier
2005-04-08 23:53 ` Kim F. Storm
@ 2005-04-12 17:49 ` Robert J. Chassell
2005-04-12 19:51 ` Stefan Monnier
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-04-12 17:49 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-12 17:49 ` Robert J. Chassell
@ 2005-04-12 19:51 ` Stefan Monnier
2005-04-12 21:45 ` David Kastrup
2005-04-13 18:31 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2005-04-12 19:51 UTC (permalink / raw
Cc: emacs-devel
> (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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-12 17:49 ` Robert J. Chassell
2005-04-12 19:51 ` Stefan Monnier
@ 2005-04-12 21:45 ` David Kastrup
2005-04-13 11:10 ` Robert J. Chassell
2005-04-13 18:31 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: David Kastrup @ 2005-04-12 21:45 UTC (permalink / raw
Cc: Stefan Monnier, emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-12 21:45 ` David Kastrup
@ 2005-04-13 11:10 ` Robert J. Chassell
0 siblings, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-04-13 11:10 UTC (permalink / raw
Cc: monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-12 17:49 ` Robert J. Chassell
2005-04-12 19:51 ` Stefan Monnier
2005-04-12 21:45 ` David Kastrup
@ 2005-04-13 18:31 ` Richard Stallman
2005-04-13 19:54 ` David Kastrup
2 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-04-13 18:31 UTC (permalink / raw
Cc: monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-13 18:31 ` Richard Stallman
@ 2005-04-13 19:54 ` David Kastrup
2005-04-14 19:03 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: David Kastrup @ 2005-04-13 19:54 UTC (permalink / raw
Cc: bob, monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-13 19:54 ` David Kastrup
@ 2005-04-14 19:03 ` Richard Stallman
2005-04-15 0:41 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-04-14 19:03 UTC (permalink / raw
Cc: bob, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-14 19:03 ` Richard Stallman
@ 2005-04-15 0:41 ` Robert J. Chassell
2005-04-16 2:58 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-04-15 0:41 UTC (permalink / raw
Cc: monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-15 0:41 ` Robert J. Chassell
@ 2005-04-16 2:58 ` Richard Stallman
2005-04-20 10:42 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-04-16 2:58 UTC (permalink / raw
Cc: monnier, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-16 2:58 ` Richard Stallman
@ 2005-04-20 10:42 ` Robert J. Chassell
2005-04-20 21:42 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-04-20 10:42 UTC (permalink / raw
[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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-20 10:42 ` Robert J. Chassell
@ 2005-04-20 21:42 ` Richard Stallman
2005-04-22 22:46 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-04-20 21:42 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-20 21:42 ` Richard Stallman
@ 2005-04-22 22:46 ` Robert J. Chassell
2005-04-23 22:24 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-04-22 22:46 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-22 22:46 ` Robert J. Chassell
@ 2005-04-23 22:24 ` Richard Stallman
2005-04-25 10:23 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-04-23 22:24 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-23 22:24 ` Richard Stallman
@ 2005-04-25 10:23 ` Robert J. Chassell
2005-04-26 10:05 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-04-25 10:23 UTC (permalink / raw
Cc: emacs-devel
[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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-25 10:23 ` Robert J. Chassell
@ 2005-04-26 10:05 ` Richard Stallman
2005-05-04 11:31 ` Robert J. Chassell
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-04-26 10:05 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-04-26 10:05 ` Richard Stallman
@ 2005-05-04 11:31 ` Robert J. Chassell
2005-05-05 14:13 ` Stefan Monnier
2005-05-05 19:46 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-04 11:31 UTC (permalink / raw
[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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* bootstrap from scratch
@ 2005-05-04 19:59 ` Robert J. Chassell
2005-05-05 0:24 ` Ed Reingold
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-04 19:59 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-04 19:59 ` bootstrap from scratch Robert J. Chassell
@ 2005-05-05 0:24 ` Ed Reingold
2005-05-05 11:21 ` Robert J. Chassell
2005-05-05 1:32 ` Marcelo Toledo
2005-05-05 19:33 ` Glenn Morris
2 siblings, 1 reply; 1364+ messages in thread
From: Ed Reingold @ 2005-05-05 0:24 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-04 19:59 ` bootstrap from scratch Robert J. Chassell
2005-05-05 0:24 ` Ed Reingold
@ 2005-05-05 1:32 ` Marcelo Toledo
2005-05-05 19:33 ` Glenn Morris
2 siblings, 0 replies; 1364+ messages in thread
From: Marcelo Toledo @ 2005-05-05 1:32 UTC (permalink / raw
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 0:24 ` Ed Reingold
@ 2005-05-05 11:21 ` Robert J. Chassell
2005-05-05 17:18 ` Ed Reingold
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-05 11:21 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-04 11:31 ` Robert J. Chassell
@ 2005-05-05 14:13 ` Stefan Monnier
2005-05-05 17:56 ` Robert J. Chassell
2005-05-05 19:46 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2005-05-05 14:13 UTC (permalink / raw
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 11:21 ` Robert J. Chassell
@ 2005-05-05 17:18 ` Ed Reingold
2005-05-05 18:42 ` Alan Shutko
2005-05-06 18:51 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Ed Reingold @ 2005-05-05 17:18 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-05 14:13 ` Stefan Monnier
@ 2005-05-05 17:56 ` Robert J. Chassell
2005-05-05 22:45 ` Kevin Rodgers
2005-05-06 18:57 ` Richard Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-05 17:56 UTC (permalink / raw
Cc: emacs-devel
... 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 17:18 ` Ed Reingold
@ 2005-05-05 18:42 ` Alan Shutko
2005-05-05 19:10 ` Ed Reingold
2005-05-05 19:24 ` Alan Shutko
2005-05-06 18:51 ` Richard Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Alan Shutko @ 2005-05-05 18:42 UTC (permalink / raw
Cc: 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.
--
Alan Shutko <ats@acm.org> - I am the rocks.
"City Morgue--you kill 'em, we chill 'em; you stab 'em, we slab 'em!"
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 18:42 ` Alan Shutko
@ 2005-05-05 19:10 ` Ed Reingold
2005-05-05 19:24 ` Alan Shutko
1 sibling, 0 replies; 1364+ messages in thread
From: Ed Reingold @ 2005-05-05 19:10 UTC (permalink / raw
Cc: emacs-devel
> 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!!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 18:42 ` Alan Shutko
2005-05-05 19:10 ` Ed Reingold
@ 2005-05-05 19:24 ` Alan Shutko
2005-05-05 19:30 ` Ed Reingold
` (4 more replies)
1 sibling, 5 replies; 1364+ messages in thread
From: Alan Shutko @ 2005-05-05 19:24 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 19:24 ` Alan Shutko
@ 2005-05-05 19:30 ` Ed Reingold
2005-05-05 19:37 ` Glenn Morris
` (3 subsequent siblings)
4 siblings, 0 replies; 1364+ messages in thread
From: Ed Reingold @ 2005-05-05 19:30 UTC (permalink / raw
Cc: Glenn Morris, emacs-devel
> 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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-04 19:59 ` bootstrap from scratch Robert J. Chassell
2005-05-05 0:24 ` Ed Reingold
2005-05-05 1:32 ` Marcelo Toledo
@ 2005-05-05 19:33 ` Glenn Morris
2 siblings, 0 replies; 1364+ messages in thread
From: Glenn Morris @ 2005-05-05 19:33 UTC (permalink / raw
Cc: Ed Reingold, emacs-devel
"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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 19:24 ` Alan Shutko
2005-05-05 19:30 ` Ed Reingold
@ 2005-05-05 19:37 ` Glenn Morris
2005-05-05 19:42 ` org.el fix Alan Shutko
2005-05-05 19:54 ` bootstrap from scratch Stefan Monnier
` (2 subsequent siblings)
4 siblings, 1 reply; 1364+ messages in thread
From: Glenn Morris @ 2005-05-05 19:37 UTC (permalink / raw
Cc: reingold, emacs-devel
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! :)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* org.el fix
2005-05-05 19:37 ` Glenn Morris
@ 2005-05-05 19:42 ` Alan Shutko
0 siblings, 0 replies; 1364+ messages in thread
From: Alan Shutko @ 2005-05-05 19:42 UTC (permalink / raw
Cc: Carsten Dominik
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-04 11:31 ` Robert J. Chassell
2005-05-05 14:13 ` Stefan Monnier
@ 2005-05-05 19:46 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-05-05 19:46 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 19:24 ` Alan Shutko
2005-05-05 19:30 ` Ed Reingold
2005-05-05 19:37 ` Glenn Morris
@ 2005-05-05 19:54 ` Stefan Monnier
2005-05-05 20:10 ` Glenn Morris
2005-05-05 20:02 ` Glenn Morris
2005-05-06 18:50 ` Richard Stallman
4 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2005-05-05 19:54 UTC (permalink / raw
Cc: reingold, Glenn Morris, emacs-devel
> On load, appt.el calls (appt-activate 1).
That's a bug.
Stefan
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 19:24 ` Alan Shutko
` (2 preceding siblings ...)
2005-05-05 19:54 ` bootstrap from scratch Stefan Monnier
@ 2005-05-05 20:02 ` Glenn Morris
2005-05-06 18:50 ` Richard Stallman
4 siblings, 0 replies; 1364+ messages in thread
From: Glenn Morris @ 2005-05-05 20:02 UTC (permalink / raw
Cc: reingold, emacs-devel
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...
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 19:54 ` bootstrap from scratch Stefan Monnier
@ 2005-05-05 20:10 ` Glenn Morris
2005-05-05 22:29 ` Kim F. Storm
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Glenn Morris @ 2005-05-05 20:10 UTC (permalink / raw
Cc: reingold, Alan Shutko, emacs-devel
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".
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 20:10 ` Glenn Morris
@ 2005-05-05 22:29 ` Kim F. Storm
2005-05-05 23:28 ` Jason Rumney
2005-05-06 18:50 ` Richard Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Kim F. Storm @ 2005-05-05 22:29 UTC (permalink / raw
Cc: reingold, Alan Shutko, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-05 17:56 ` Robert J. Chassell
@ 2005-05-05 22:45 ` Kevin Rodgers
2005-05-06 15:34 ` Robert J. Chassell
2005-05-06 18:57 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Kevin Rodgers @ 2005-05-05 22:45 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 20:10 ` Glenn Morris
2005-05-05 22:29 ` Kim F. Storm
@ 2005-05-05 23:28 ` Jason Rumney
2005-05-06 10:30 ` bootstrap from scratch [is now appt activation] Marcelo Toledo
2005-05-06 18:51 ` bootstrap from scratch Richard Stallman
2005-05-06 18:50 ` Richard Stallman
2 siblings, 2 replies; 1364+ messages in thread
From: Jason Rumney @ 2005-05-05 23:28 UTC (permalink / raw
Cc: reingold, Alan Shutko, Stefan Monnier, emacs-devel
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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch [is now appt activation]
2005-05-05 23:28 ` Jason Rumney
@ 2005-05-06 10:30 ` Marcelo Toledo
2005-05-06 22:23 ` Jason Rumney
2005-05-06 18:51 ` bootstrap from scratch Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Marcelo Toledo @ 2005-05-06 10:30 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-05 22:45 ` Kevin Rodgers
@ 2005-05-06 15:34 ` Robert J. Chassell
2005-05-06 17:32 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-06 15:34 UTC (permalink / raw
Cc: emacs-devel
> ... 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-06 15:34 ` Robert J. Chassell
@ 2005-05-06 17:32 ` Stefan Monnier
2005-05-06 18:49 ` Robert J. Chassell
2005-05-06 19:03 ` RMAIL slows Robert J. Chassell
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2005-05-06 17:32 UTC (permalink / raw
Cc: Kevin Rodgers, emacs-devel
>> ... 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-06 17:32 ` Stefan Monnier
@ 2005-05-06 18:49 ` Robert J. Chassell
2005-05-06 20:50 ` Stefan Monnier
2005-05-06 19:03 ` RMAIL slows Robert J. Chassell
1 sibling, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-06 18:49 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 19:24 ` Alan Shutko
` (3 preceding siblings ...)
2005-05-05 20:02 ` Glenn Morris
@ 2005-05-06 18:50 ` Richard Stallman
4 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-05-06 18:50 UTC (permalink / raw
Cc: reingold, gmorris, emacs-devel
* 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 20:10 ` Glenn Morris
2005-05-05 22:29 ` Kim F. Storm
2005-05-05 23:28 ` Jason Rumney
@ 2005-05-06 18:50 ` Richard Stallman
2005-05-06 20:38 ` Glenn Morris
2 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-05-06 18:50 UTC (permalink / raw
Cc: monnier
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 17:18 ` Ed Reingold
2005-05-05 18:42 ` Alan Shutko
@ 2005-05-06 18:51 ` Richard Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-05-06 18:51 UTC (permalink / raw
Cc: bob, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-05 23:28 ` Jason Rumney
2005-05-06 10:30 ` bootstrap from scratch [is now appt activation] Marcelo Toledo
@ 2005-05-06 18:51 ` Richard Stallman
2005-05-06 22:26 ` Jason Rumney
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-05-06 18:51 UTC (permalink / raw
Cc: reingold, gmorris+emacs, ats, monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-05 17:56 ` Robert J. Chassell
2005-05-05 22:45 ` Kevin Rodgers
@ 2005-05-06 18:57 ` Richard Stallman
2005-05-06 19:20 ` Robert J. Chassell
1 sibling, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-05-06 18:57 UTC (permalink / raw
Cc: monnier, emacs-devel
(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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-06 17:32 ` Stefan Monnier
2005-05-06 18:49 ` Robert J. Chassell
@ 2005-05-06 19:03 ` Robert J. Chassell
1 sibling, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-06 19:03 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
[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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-06 18:57 ` Richard Stallman
@ 2005-05-06 19:20 ` Robert J. Chassell
0 siblings, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-06 19:20 UTC (permalink / raw
Cc: monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-06 18:50 ` Richard Stallman
@ 2005-05-06 20:38 ` Glenn Morris
0 siblings, 0 replies; 1364+ messages in thread
From: Glenn Morris @ 2005-05-06 20:38 UTC (permalink / raw
Cc: reingold, Alan Shutko, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-06 18:49 ` Robert J. Chassell
@ 2005-05-06 20:50 ` Stefan Monnier
2005-05-07 11:08 ` Robert J. Chassell
2005-05-10 11:04 ` Robert J. Chassell
0 siblings, 2 replies; 1364+ messages in thread
From: Stefan Monnier @ 2005-05-06 20:50 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch [is now appt activation]
2005-05-06 10:30 ` bootstrap from scratch [is now appt activation] Marcelo Toledo
@ 2005-05-06 22:23 ` Jason Rumney
0 siblings, 0 replies; 1364+ messages in thread
From: Jason Rumney @ 2005-05-06 22:23 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-06 18:51 ` bootstrap from scratch Richard Stallman
@ 2005-05-06 22:26 ` Jason Rumney
2005-05-07 18:35 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Jason Rumney @ 2005-05-06 22:26 UTC (permalink / raw
Cc: reingold, gmorris+emacs, ats, monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-06 20:50 ` Stefan Monnier
@ 2005-05-07 11:08 ` Robert J. Chassell
2005-05-10 11:04 ` Robert J. Chassell
1 sibling, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-07 11:08 UTC (permalink / raw
Cc: ihs_4664, emacs-devel
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: bootstrap from scratch
2005-05-06 22:26 ` Jason Rumney
@ 2005-05-07 18:35 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-05-07 18:35 UTC (permalink / raw
Cc: reingold, gmorris+emacs, ats, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: RMAIL slows
2005-05-06 20:50 ` Stefan Monnier
2005-05-07 11:08 ` Robert J. Chassell
@ 2005-05-10 11:04 ` Robert J. Chassell
2005-05-10 15:56 ` Should overlays evaporate by default? Peter Whaite
1 sibling, 1 reply; 1364+ messages in thread
From: Robert J. Chassell @ 2005-05-10 11:04 UTC (permalink / raw
Cc: emacs-devel
[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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Should overlays evaporate by default?
2005-05-10 11:04 ` Robert J. Chassell
@ 2005-05-10 15:56 ` Peter Whaite
2005-05-11 16:27 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-05-10 15:56 UTC (permalink / raw
Cc: bob, Stefan Monnier
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-10 15:56 ` Should overlays evaporate by default? Peter Whaite
@ 2005-05-11 16:27 ` Richard Stallman
2005-05-12 8:18 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-05-11 16:27 UTC (permalink / raw
Cc: bob, monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-11 16:27 ` Richard Stallman
@ 2005-05-12 8:18 ` Kim F. Storm
2005-05-13 1:34 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2005-05-12 8:18 UTC (permalink / raw
Cc: bob, monnier, Peter Whaite, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-12 8:18 ` Kim F. Storm
@ 2005-05-13 1:34 ` Richard Stallman
2005-05-13 8:17 ` Kim F. Storm
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-05-13 1:34 UTC (permalink / raw
Cc: bob, monnier, emacs, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-13 1:34 ` Richard Stallman
@ 2005-05-13 8:17 ` Kim F. Storm
2005-05-14 0:25 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Kim F. Storm @ 2005-05-13 8:17 UTC (permalink / raw
Cc: bob, monnier, emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-13 8:17 ` Kim F. Storm
@ 2005-05-14 0:25 ` Richard Stallman
2005-05-16 14:59 ` Peter Whaite
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-05-14 0:25 UTC (permalink / raw
Cc: bob, monnier, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-14 0:25 ` Richard Stallman
@ 2005-05-16 14:59 ` Peter Whaite
2005-05-16 21:21 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-05-16 14:59 UTC (permalink / raw
Cc: bob, emacs-devel, monnier, Kim F. Storm
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-16 14:59 ` Peter Whaite
@ 2005-05-16 21:21 ` Richard Stallman
2005-05-17 16:20 ` Peter Whaite
2005-05-18 0:15 ` Thien-Thi Nguyen
0 siblings, 2 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-05-16 21:21 UTC (permalink / raw
Cc: bob, emacs-devel, monnier, storm
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-16 21:21 ` Richard Stallman
@ 2005-05-17 16:20 ` Peter Whaite
2005-05-18 5:19 ` Richard Stallman
2005-05-18 0:15 ` Thien-Thi Nguyen
1 sibling, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-05-17 16:20 UTC (permalink / raw
Cc: bob, emacs-devel, monnier, storm
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-16 21:21 ` Richard Stallman
2005-05-17 16:20 ` Peter Whaite
@ 2005-05-18 0:15 ` Thien-Thi Nguyen
2005-05-18 22:45 ` Richard Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2005-05-18 0:15 UTC (permalink / raw
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-17 16:20 ` Peter Whaite
@ 2005-05-18 5:19 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-05-18 5:19 UTC (permalink / raw
Cc: bob, emacs-devel, monnier, storm
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-18 0:15 ` Thien-Thi Nguyen
@ 2005-05-18 22:45 ` Richard Stallman
2005-05-19 8:24 ` Thien-Thi Nguyen
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-05-18 22:45 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-18 22:45 ` Richard Stallman
@ 2005-05-19 8:24 ` Thien-Thi Nguyen
2005-05-19 22:39 ` Richard Stallman
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2005-05-19 8:24 UTC (permalink / raw
Cc: emacs-devel
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");
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-19 8:24 ` Thien-Thi Nguyen
@ 2005-05-19 22:39 ` Richard Stallman
2005-05-20 19:15 ` Peter Whaite
2005-05-27 19:23 ` Should overlays evaporate by default? Conclusion: No! Peter Whaite
2 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-05-19 22:39 UTC (permalink / raw
Cc: emacs-devel
Thanks for writing this patch. Now someone can run it
so as to look for code that ought to set evaporate properties.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default?
2005-05-19 8:24 ` Thien-Thi Nguyen
2005-05-19 22:39 ` Richard Stallman
@ 2005-05-20 19:15 ` Peter Whaite
2005-05-27 19:23 ` Should overlays evaporate by default? Conclusion: No! Peter Whaite
2 siblings, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-05-20 19:15 UTC (permalink / raw
Cc: rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default? Conclusion: No!
2005-05-19 8:24 ` Thien-Thi Nguyen
2005-05-19 22:39 ` Richard Stallman
2005-05-20 19:15 ` Peter Whaite
@ 2005-05-27 19:23 ` Peter Whaite
2005-05-28 11:52 ` Richard Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-05-27 19:23 UTC (permalink / raw
Cc: rms, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default? Conclusion: No!
2005-05-27 19:23 ` Should overlays evaporate by default? Conclusion: No! Peter Whaite
@ 2005-05-28 11:52 ` Richard Stallman
2005-05-30 16:22 ` Peter Whaite
0 siblings, 1 reply; 1364+ messages in thread
From: Richard Stallman @ 2005-05-28 11:52 UTC (permalink / raw
Cc: ttn, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default? Conclusion: No!
2005-05-28 11:52 ` Richard Stallman
@ 2005-05-30 16:22 ` Peter Whaite
2005-05-31 10:54 ` Richard Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-05-30 16:22 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Should overlays evaporate by default? Conclusion: No!
2005-05-30 16:22 ` Peter Whaite
@ 2005-05-31 10:54 ` Richard Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard Stallman @ 2005-05-31 10:54 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* SPC in custom-mode
@ 2005-07-05 17:54 Lennart Borgman
2005-07-07 17:05 ` Per Abrahamsen
0 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-07-05 17:54 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-05 17:54 SPC in custom-mode Lennart Borgman
@ 2005-07-07 17:05 ` Per Abrahamsen
2005-07-07 17:37 ` Lennart Borgman
2005-07-07 20:34 ` Peter Whaite
0 siblings, 2 replies; 1364+ messages in thread
From: Per Abrahamsen @ 2005-07-07 17:05 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 17:05 ` Per Abrahamsen
@ 2005-07-07 17:37 ` Lennart Borgman
2005-07-08 10:17 ` Per Abrahamsen
2005-07-07 20:34 ` Peter Whaite
1 sibling, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-07-07 17:37 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 17:05 ` Per Abrahamsen
2005-07-07 17:37 ` Lennart Borgman
@ 2005-07-07 20:34 ` Peter Whaite
2005-07-07 21:21 ` Lennart Borgman
2005-07-08 4:36 ` Richard M. Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-07-07 20:34 UTC (permalink / raw
> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 20:34 ` Peter Whaite
@ 2005-07-07 21:21 ` Lennart Borgman
2005-07-07 23:18 ` Peter Whaite
2005-07-08 4:36 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-07-07 21:21 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 21:21 ` Lennart Borgman
@ 2005-07-07 23:18 ` Peter Whaite
2005-07-07 23:27 ` Lennart Borgman
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-07-07 23:18 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 23:18 ` Peter Whaite
@ 2005-07-07 23:27 ` Lennart Borgman
2005-07-08 6:52 ` Mathias Dahl
2005-07-08 7:24 ` Joakim Verona
0 siblings, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-07-07 23:27 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 20:34 ` Peter Whaite
2005-07-07 21:21 ` Lennart Borgman
@ 2005-07-08 4:36 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-07-08 4:36 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 23:27 ` Lennart Borgman
@ 2005-07-08 6:52 ` Mathias Dahl
2005-07-08 7:24 ` Joakim Verona
1 sibling, 0 replies; 1364+ messages in thread
From: Mathias Dahl @ 2005-07-08 6:52 UTC (permalink / raw
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...
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 23:27 ` Lennart Borgman
2005-07-08 6:52 ` Mathias Dahl
@ 2005-07-08 7:24 ` Joakim Verona
1 sibling, 0 replies; 1364+ messages in thread
From: Joakim Verona @ 2005-07-08 7:24 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: SPC in custom-mode
2005-07-07 17:37 ` Lennart Borgman
@ 2005-07-08 10:17 ` Per Abrahamsen
0 siblings, 0 replies; 1364+ messages in thread
From: Per Abrahamsen @ 2005-07-08 10:17 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* fancy-splash-screen customize group...
@ 2005-12-02 2:13 David Kastrup
2005-12-03 1:19 ` Richard M. Stallman
2005-12-03 11:26 ` Romain Francoise
0 siblings, 2 replies; 1364+ messages in thread
From: David Kastrup @ 2005-12-02 2:13 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-02 2:13 fancy-splash-screen customize group David Kastrup
@ 2005-12-03 1:19 ` Richard M. Stallman
2005-12-03 8:20 ` David Kastrup
2005-12-03 11:26 ` Romain Francoise
1 sibling, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-03 1:19 UTC (permalink / raw
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-03 1:19 ` Richard M. Stallman
@ 2005-12-03 8:20 ` David Kastrup
2005-12-04 3:08 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: David Kastrup @ 2005-12-03 8:20 UTC (permalink / raw
Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-02 2:13 fancy-splash-screen customize group David Kastrup
2005-12-03 1:19 ` Richard M. Stallman
@ 2005-12-03 11:26 ` Romain Francoise
2005-12-03 18:03 ` David Kastrup
1 sibling, 1 reply; 1364+ messages in thread
From: Romain Francoise @ 2005-12-03 11:26 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-03 11:26 ` Romain Francoise
@ 2005-12-03 18:03 ` David Kastrup
2005-12-04 18:51 ` Chong Yidong
2005-12-04 21:18 ` Richard M. Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: David Kastrup @ 2005-12-03 18:03 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-03 8:20 ` David Kastrup
@ 2005-12-04 3:08 ` Richard M. Stallman
2005-12-04 11:54 ` David Kastrup
2005-12-04 15:17 ` Stefan Monnier
0 siblings, 2 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-04 3:08 UTC (permalink / raw
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-04 3:08 ` Richard M. Stallman
@ 2005-12-04 11:54 ` David Kastrup
2005-12-04 15:17 ` Stefan Monnier
1 sibling, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2005-12-04 11:54 UTC (permalink / raw
Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-04 3:08 ` Richard M. Stallman
2005-12-04 11:54 ` David Kastrup
@ 2005-12-04 15:17 ` Stefan Monnier
1 sibling, 0 replies; 1364+ messages in thread
From: Stefan Monnier @ 2005-12-04 15:17 UTC (permalink / raw
Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-03 18:03 ` David Kastrup
@ 2005-12-04 18:51 ` Chong Yidong
2005-12-04 18:54 ` Chong Yidong
2005-12-04 21:18 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Chong Yidong @ 2005-12-04 18:51 UTC (permalink / raw
Cc: Romain Francoise, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-04 18:51 ` Chong Yidong
@ 2005-12-04 18:54 ` Chong Yidong
2005-12-04 21:38 ` Drew Adams
0 siblings, 1 reply; 1364+ messages in thread
From: Chong Yidong @ 2005-12-04 18:54 UTC (permalink / raw
Cc: Romain Francoise, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-03 18:03 ` David Kastrup
2005-12-04 18:51 ` Chong Yidong
@ 2005-12-04 21:18 ` Richard M. Stallman
2005-12-04 21:22 ` David Kastrup
2005-12-10 4:07 ` Luc Teirlinck
1 sibling, 2 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-04 21:18 UTC (permalink / raw
Cc: romain, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-04 21:18 ` Richard M. Stallman
@ 2005-12-04 21:22 ` David Kastrup
2005-12-10 4:07 ` Luc Teirlinck
1 sibling, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2005-12-04 21:22 UTC (permalink / raw
Cc: romain, emacs-devel
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: fancy-splash-screen customize group...
2005-12-04 18:54 ` Chong Yidong
@ 2005-12-04 21:38 ` Drew Adams
2005-12-05 16:38 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Drew Adams @ 2005-12-04 21:38 UTC (permalink / raw
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...
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-04 21:38 ` Drew Adams
@ 2005-12-05 16:38 ` Richard M. Stallman
2005-12-05 17:52 ` Chong Yidong
0 siblings, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-05 16:38 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-05 16:38 ` Richard M. Stallman
@ 2005-12-05 17:52 ` Chong Yidong
2005-12-05 18:47 ` Peter Whaite
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Chong Yidong @ 2005-12-05 17:52 UTC (permalink / raw
Cc: Drew Adams, emacs-devel
"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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-05 17:52 ` Chong Yidong
@ 2005-12-05 18:47 ` Peter Whaite
2005-12-06 0:02 ` Xavier Maillard
2005-12-06 16:41 ` Richard M. Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-05 18:47 UTC (permalink / raw
Cc: Chong Yidong
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-05 17:52 ` Chong Yidong
2005-12-05 18:47 ` Peter Whaite
@ 2005-12-06 0:02 ` Xavier Maillard
2005-12-06 16:42 ` Richard M. Stallman
2005-12-06 16:41 ` Richard M. Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Xavier Maillard @ 2005-12-06 0:02 UTC (permalink / raw
Cc: rms, drew.adams, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-05 17:52 ` Chong Yidong
2005-12-05 18:47 ` Peter Whaite
2005-12-06 0:02 ` Xavier Maillard
@ 2005-12-06 16:41 ` Richard M. Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-06 16:41 UTC (permalink / raw
Cc: drew.adams, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 0:02 ` Xavier Maillard
@ 2005-12-06 16:42 ` Richard M. Stallman
2005-12-06 17:17 ` Chong Yidong
2005-12-07 16:38 ` Drew Adams
0 siblings, 2 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-06 16:42 UTC (permalink / raw
Cc: cyd, drew.adams, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 16:42 ` Richard M. Stallman
@ 2005-12-06 17:17 ` Chong Yidong
2005-12-06 19:09 ` Peter Whaite
2005-12-07 17:06 ` Richard M. Stallman
2005-12-07 16:38 ` Drew Adams
1 sibling, 2 replies; 1364+ messages in thread
From: Chong Yidong @ 2005-12-06 17:17 UTC (permalink / raw
Cc: zedek, drew.adams, emacs-devel
"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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 17:17 ` Chong Yidong
@ 2005-12-06 19:09 ` Peter Whaite
2005-12-06 20:31 ` Lennart Borgman
` (4 more replies)
2005-12-07 17:06 ` Richard M. Stallman
1 sibling, 5 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-06 19:09 UTC (permalink / raw
Cc: zedek, Chong Yidong, rms, drew.adams
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 19:09 ` Peter Whaite
@ 2005-12-06 20:31 ` Lennart Borgman
2005-12-06 21:19 ` Chong Yidong
2005-12-07 17:07 ` fancy-splash-screen customize group Richard M. Stallman
2005-12-07 4:25 ` Luc Teirlinck
` (3 subsequent siblings)
4 siblings, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-06 20:31 UTC (permalink / raw
Cc: zedek, Chong Yidong, rms, drew.adams, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 20:31 ` Lennart Borgman
@ 2005-12-06 21:19 ` Chong Yidong
2005-12-06 23:01 ` Jason Rumney
2005-12-06 23:18 ` Lennart Borgman
2005-12-07 17:07 ` fancy-splash-screen customize group Richard M. Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Chong Yidong @ 2005-12-06 21:19 UTC (permalink / raw
Cc: zedek, drew.adams, rms, Peter Whaite, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 21:19 ` Chong Yidong
@ 2005-12-06 23:01 ` Jason Rumney
2005-12-06 23:28 ` Luc Teirlinck
2005-12-06 23:18 ` Lennart Borgman
1 sibling, 1 reply; 1364+ messages in thread
From: Jason Rumney @ 2005-12-06 23:01 UTC (permalink / raw
Cc: rms, Lennart Borgman, Peter Whaite, emacs-devel, zedek,
drew.adams
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 21:19 ` Chong Yidong
2005-12-06 23:01 ` Jason Rumney
@ 2005-12-06 23:18 ` Lennart Borgman
2005-12-07 7:57 ` Help links (was: fancy-splash-screen customize group...) Juri Linkov
1 sibling, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-06 23:18 UTC (permalink / raw
Cc: zedek, emacs-devel, rms, drew.adams, Peter Whaite
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 23:01 ` Jason Rumney
@ 2005-12-06 23:28 ` Luc Teirlinck
2005-12-06 23:37 ` Lennart Borgman
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-06 23:28 UTC (permalink / raw
Cc: rms, lennart.borgman.073, cyd, emacs, emacs-devel, zedek,
drew.adams
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 23:28 ` Luc Teirlinck
@ 2005-12-06 23:37 ` Lennart Borgman
2005-12-07 0:11 ` Luc Teirlinck
2005-12-07 0:14 ` Luc Teirlinck
0 siblings, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-06 23:37 UTC (permalink / raw
Cc: rms, cyd, emacs, emacs-devel, zedek, jasonr, drew.adams
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 23:37 ` Lennart Borgman
@ 2005-12-07 0:11 ` Luc Teirlinck
2005-12-07 0:34 ` Lennart Borgman
2005-12-07 17:37 ` Peter Whaite
2005-12-07 0:14 ` Luc Teirlinck
1 sibling, 2 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-07 0:11 UTC (permalink / raw
Cc: rms, cyd, emacs, jasonr, zedek, emacs-devel, drew.adams
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 23:37 ` Lennart Borgman
2005-12-07 0:11 ` Luc Teirlinck
@ 2005-12-07 0:14 ` Luc Teirlinck
1 sibling, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-07 0:14 UTC (permalink / raw
Cc: rms, cyd, emacs, jasonr, zedek, emacs-devel, drew.adams
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 0:11 ` Luc Teirlinck
@ 2005-12-07 0:34 ` Lennart Borgman
2005-12-07 17:39 ` Xavier Maillard
2005-12-07 17:37 ` Peter Whaite
1 sibling, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-07 0:34 UTC (permalink / raw
Cc: rms, cyd, emacs, emacs-devel, zedek, jasonr, drew.adams
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]
[not found] <E1EjJLn-0005bC-6Q@fencepost.gnu.org>
@ 2005-12-07 2:10 ` Michael Kifer
2005-12-07 22:58 ` Richard M. Stallman
2005-12-08 13:24 ` Lőrentey Károly
0 siblings, 2 replies; 1364+ messages in thread
From: Michael Kifer @ 2005-12-07 2:10 UTC (permalink / raw
Cc: rms, emacs-devel
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 -------
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 19:09 ` Peter Whaite
2005-12-06 20:31 ` Lennart Borgman
@ 2005-12-07 4:25 ` Luc Teirlinck
2005-12-07 16:45 ` Drew Adams
` (2 subsequent siblings)
4 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-07 4:25 UTC (permalink / raw
Cc: zedek, cyd, rms, drew.adams, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Help links (was: fancy-splash-screen customize group...)
2005-12-06 23:18 ` Lennart Borgman
@ 2005-12-07 7:57 ` Juri Linkov
2005-12-07 9:05 ` Help links Lennart Borgman
0 siblings, 1 reply; 1364+ messages in thread
From: Juri Linkov @ 2005-12-07 7:57 UTC (permalink / raw
Cc: rms, cyd, emacs, emacs-devel, zedek, drew.adams
>>>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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Help links
2005-12-07 7:57 ` Help links (was: fancy-splash-screen customize group...) Juri Linkov
@ 2005-12-07 9:05 ` Lennart Borgman
2005-12-07 22:59 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-07 9:05 UTC (permalink / raw
Cc: rms, cyd, emacs, emacs-devel, zedek, drew.adams
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: fancy-splash-screen customize group...
2005-12-06 16:42 ` Richard M. Stallman
2005-12-06 17:17 ` Chong Yidong
@ 2005-12-07 16:38 ` Drew Adams
2005-12-08 4:55 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Drew Adams @ 2005-12-07 16:38 UTC (permalink / raw
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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: fancy-splash-screen customize group...
2005-12-06 19:09 ` Peter Whaite
2005-12-06 20:31 ` Lennart Borgman
2005-12-07 4:25 ` Luc Teirlinck
@ 2005-12-07 16:45 ` Drew Adams
2005-12-07 18:27 ` Lennart Borgman
2005-12-07 17:06 ` Richard M. Stallman
2005-12-07 17:06 ` Richard M. Stallman
4 siblings, 1 reply; 1364+ messages in thread
From: Drew Adams @ 2005-12-07 16:45 UTC (permalink / raw
> 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,...).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 17:17 ` Chong Yidong
2005-12-06 19:09 ` Peter Whaite
@ 2005-12-07 17:06 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-07 17:06 UTC (permalink / raw
Cc: zedek, drew.adams, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 19:09 ` Peter Whaite
` (2 preceding siblings ...)
2005-12-07 16:45 ` Drew Adams
@ 2005-12-07 17:06 ` Richard M. Stallman
2005-12-07 18:26 ` Peter Whaite
2005-12-07 17:06 ` Richard M. Stallman
4 siblings, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-07 17:06 UTC (permalink / raw
Cc: zedek, cyd, drew.adams, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 19:09 ` Peter Whaite
` (3 preceding siblings ...)
2005-12-07 17:06 ` Richard M. Stallman
@ 2005-12-07 17:06 ` Richard M. Stallman
2005-12-07 18:21 ` Peter Whaite
4 siblings, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-07 17:06 UTC (permalink / raw
Cc: zedek, cyd, drew.adams, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-06 20:31 ` Lennart Borgman
2005-12-06 21:19 ` Chong Yidong
@ 2005-12-07 17:07 ` Richard M. Stallman
2005-12-09 17:49 ` Lennart Borgman
1 sibling, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-07 17:07 UTC (permalink / raw
Cc: zedek, cyd, drew.adams, emacs, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 0:11 ` Luc Teirlinck
2005-12-07 0:34 ` Lennart Borgman
@ 2005-12-07 17:37 ` Peter Whaite
2005-12-07 21:28 ` Juri Linkov
1 sibling, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-12-07 17:37 UTC (permalink / raw
Cc: rms, lennart.borgman.073, cyd, jasonr, zedek, emacs-devel,
drew.adams
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 0:34 ` Lennart Borgman
@ 2005-12-07 17:39 ` Xavier Maillard
0 siblings, 0 replies; 1364+ messages in thread
From: Xavier Maillard @ 2005-12-07 17:39 UTC (permalink / raw
Cc: teirllm, rms, cyd, emacs, emacs-devel, jasonr, drew.adams
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 17:06 ` Richard M. Stallman
@ 2005-12-07 18:21 ` Peter Whaite
0 siblings, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-07 18:21 UTC (permalink / raw
Cc: zedek, cyd, drew.adams, Peter Whaite, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 17:06 ` Richard M. Stallman
@ 2005-12-07 18:26 ` Peter Whaite
2005-12-11 22:57 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-12-07 18:26 UTC (permalink / raw
Cc: zedek, cyd, drew.adams, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 16:45 ` Drew Adams
@ 2005-12-07 18:27 ` Lennart Borgman
2005-12-07 18:36 ` Drew Adams
0 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-07 18:27 UTC (permalink / raw
Cc: emacs-devel
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...
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: fancy-splash-screen customize group...
2005-12-07 18:27 ` Lennart Borgman
@ 2005-12-07 18:36 ` Drew Adams
2005-12-07 20:22 ` Lennart Borgman
2005-12-07 20:27 ` Peter Whaite
0 siblings, 2 replies; 1364+ messages in thread
From: Drew Adams @ 2005-12-07 18:36 UTC (permalink / raw
> > 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 18:36 ` Drew Adams
@ 2005-12-07 20:22 ` Lennart Borgman
2005-12-07 20:27 ` Peter Whaite
1 sibling, 0 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-07 20:22 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 18:36 ` Drew Adams
2005-12-07 20:22 ` Lennart Borgman
@ 2005-12-07 20:27 ` Peter Whaite
1 sibling, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-07 20:27 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 17:37 ` Peter Whaite
@ 2005-12-07 21:28 ` Juri Linkov
2005-12-07 22:38 ` Lennart Borgman
` (2 more replies)
0 siblings, 3 replies; 1364+ messages in thread
From: Juri Linkov @ 2005-12-07 21:28 UTC (permalink / raw
Cc: teirllm, rms, lennart.borgman.073, cyd, jasonr, zedek,
emacs-devel, drew.adams
> 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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 21:28 ` Juri Linkov
@ 2005-12-07 22:38 ` Lennart Borgman
2005-12-07 23:21 ` Peter Whaite
` (3 more replies)
2005-12-07 22:46 ` Lennart Borgman
2005-12-07 22:48 ` Peter Whaite
2 siblings, 4 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-07 22:38 UTC (permalink / raw
Cc: teirllm, rms, cyd, Peter Whaite, jasonr, zedek, emacs-devel,
drew.adams
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 21:28 ` Juri Linkov
2005-12-07 22:38 ` Lennart Borgman
@ 2005-12-07 22:46 ` Lennart Borgman
2005-12-07 22:48 ` Peter Whaite
2 siblings, 0 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-07 22:46 UTC (permalink / raw
Cc: rms
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 21:28 ` Juri Linkov
2005-12-07 22:38 ` Lennart Borgman
2005-12-07 22:46 ` Lennart Borgman
@ 2005-12-07 22:48 ` Peter Whaite
2 siblings, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-07 22:48 UTC (permalink / raw
Cc: teirllm, rms, lennart.borgman.073, cyd, Peter Whaite, jasonr,
zedek, emacs-devel, drew.adams
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]
2005-12-07 2:10 ` [evilborisnet@netscape.net: weird behavior of ediff with multiple displays] Michael Kifer
@ 2005-12-07 22:58 ` Richard M. Stallman
2005-12-07 23:53 ` Michael Kifer
2005-12-08 13:24 ` Lőrentey Károly
1 sibling, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-07 22:58 UTC (permalink / raw
Cc: emacs-devel, evilborisnet
(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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Help links
2005-12-07 9:05 ` Help links Lennart Borgman
@ 2005-12-07 22:59 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-07 22:59 UTC (permalink / raw
Cc: cyd, emacs, emacs-devel, juri, zedek, drew.adams
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 22:38 ` Lennart Borgman
@ 2005-12-07 23:21 ` Peter Whaite
2005-12-07 23:25 ` Lennart Borgman
2005-12-07 23:27 ` Luc Teirlinck
` (2 subsequent siblings)
3 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-12-07 23:21 UTC (permalink / raw
Cc: teirllm, Per Abrahamsen, cyd, jasonr, Juri Linkov, zedek,
emacs-devel, drew.adams, rms
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:21 ` Peter Whaite
@ 2005-12-07 23:25 ` Lennart Borgman
2005-12-07 23:49 ` Peter Whaite
0 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-07 23:25 UTC (permalink / raw
Cc: rms, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 22:38 ` Lennart Borgman
2005-12-07 23:21 ` Peter Whaite
@ 2005-12-07 23:27 ` Luc Teirlinck
2005-12-08 2:59 ` Chong Yidong
[not found] ` <200512072321.jB7NLMR03715@raven.dms.auburn.edu>
2005-12-11 22:57 ` Richard M. Stallman
3 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-07 23:27 UTC (permalink / raw
Cc: abraham, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
[not found] ` <200512072321.jB7NLMR03715@raven.dms.auburn.edu>
@ 2005-12-07 23:32 ` Lennart Borgman
2005-12-07 23:46 ` Luc Teirlinck
2005-12-07 23:38 ` Peter Whaite
[not found] ` <87pso8l2l7.fsf@stupidchicken.com>
2 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-07 23:32 UTC (permalink / raw
Cc: rms, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
[not found] ` <200512072321.jB7NLMR03715@raven.dms.auburn.edu>
2005-12-07 23:32 ` Lennart Borgman
@ 2005-12-07 23:38 ` Peter Whaite
2005-12-07 23:52 ` Luc Teirlinck
2005-12-08 19:27 ` Richard M. Stallman
[not found] ` <87pso8l2l7.fsf@stupidchicken.com>
2 siblings, 2 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-07 23:38 UTC (permalink / raw
Cc: lennart.borgman.073, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:32 ` Lennart Borgman
@ 2005-12-07 23:46 ` Luc Teirlinck
0 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-07 23:46 UTC (permalink / raw
Cc: rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:25 ` Lennart Borgman
@ 2005-12-07 23:49 ` Peter Whaite
2005-12-08 0:39 ` Lennart Borgman
2005-12-08 1:00 ` Juri Linkov
0 siblings, 2 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-07 23:49 UTC (permalink / raw
Cc: rms, Peter Whaite, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:38 ` Peter Whaite
@ 2005-12-07 23:52 ` Luc Teirlinck
2005-12-09 17:42 ` Peter Whaite
2005-12-08 19:27 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-07 23:52 UTC (permalink / raw
Cc: lennart.borgman.073, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]
2005-12-07 22:58 ` Richard M. Stallman
@ 2005-12-07 23:53 ` Michael Kifer
2005-12-08 19:27 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Michael Kifer @ 2005-12-07 23:53 UTC (permalink / raw
Cc: emacs-devel, evilborisnet
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:49 ` Peter Whaite
@ 2005-12-08 0:39 ` Lennart Borgman
2005-12-08 21:54 ` Peter Whaite
2005-12-08 1:00 ` Juri Linkov
1 sibling, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-08 0:39 UTC (permalink / raw
Cc: rms, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:49 ` Peter Whaite
2005-12-08 0:39 ` Lennart Borgman
@ 2005-12-08 1:00 ` Juri Linkov
2005-12-08 2:30 ` Luc Teirlinck
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: Juri Linkov @ 2005-12-08 1:00 UTC (permalink / raw
>> 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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 1:00 ` Juri Linkov
@ 2005-12-08 2:30 ` Luc Teirlinck
2005-12-08 21:57 ` Juri Linkov
2005-12-08 2:42 ` fancy-splash-screen customize group Luc Teirlinck
2005-12-08 3:21 ` Luc Teirlinck
2 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-08 2:30 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 1:00 ` Juri Linkov
2005-12-08 2:30 ` Luc Teirlinck
@ 2005-12-08 2:42 ` Luc Teirlinck
2005-12-08 3:21 ` Luc Teirlinck
2 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-08 2:42 UTC (permalink / raw
Cc: emacs-devel
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:27 ` Luc Teirlinck
@ 2005-12-08 2:59 ` Chong Yidong
0 siblings, 0 replies; 1364+ messages in thread
From: Chong Yidong @ 2005-12-08 2:59 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 1:00 ` Juri Linkov
2005-12-08 2:30 ` Luc Teirlinck
2005-12-08 2:42 ` fancy-splash-screen customize group Luc Teirlinck
@ 2005-12-08 3:21 ` Luc Teirlinck
2005-12-08 8:47 ` Lennart Borgman
2 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-08 3:21 UTC (permalink / raw
Cc: emacs-devel
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 16:38 ` Drew Adams
@ 2005-12-08 4:55 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-08 4:55 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 3:21 ` Luc Teirlinck
@ 2005-12-08 8:47 ` Lennart Borgman
2005-12-08 15:38 ` Luc Teirlinck
2005-12-08 16:38 ` Luc Teirlinck
0 siblings, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-08 8:47 UTC (permalink / raw
Cc: juri, emacs-devel
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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]
2005-12-07 2:10 ` [evilborisnet@netscape.net: weird behavior of ediff with multiple displays] Michael Kifer
2005-12-07 22:58 ` Richard M. Stallman
@ 2005-12-08 13:24 ` Lőrentey Károly
1 sibling, 0 replies; 1364+ messages in thread
From: Lőrentey Károly @ 2005-12-08 13:24 UTC (permalink / raw
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 8:47 ` Lennart Borgman
@ 2005-12-08 15:38 ` Luc Teirlinck
2005-12-08 16:38 ` Luc Teirlinck
1 sibling, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-08 15:38 UTC (permalink / raw
Cc: juri, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 8:47 ` Lennart Borgman
2005-12-08 15:38 ` Luc Teirlinck
@ 2005-12-08 16:38 ` Luc Teirlinck
1 sibling, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-08 16:38 UTC (permalink / raw
Cc: juri, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:38 ` Peter Whaite
2005-12-07 23:52 ` Luc Teirlinck
@ 2005-12-08 19:27 ` Richard M. Stallman
2005-12-08 21:34 ` Peter Whaite
2005-12-09 2:25 ` Luc Teirlinck
1 sibling, 2 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-08 19:27 UTC (permalink / raw
Cc: lennart.borgman.073, teirllm, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]
2005-12-07 23:53 ` Michael Kifer
@ 2005-12-08 19:27 ` Richard M. Stallman
2005-12-08 20:34 ` Lőrentey Károly
2005-12-08 21:27 ` Michael Kifer
0 siblings, 2 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-08 19:27 UTC (permalink / raw
Cc: emacs-devel, evilborisnet
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
[not found] ` <87pso8l2l7.fsf@stupidchicken.com>
@ 2005-12-08 19:29 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-08 19:29 UTC (permalink / raw
Cc: teirllm, abraham, lennart.borgman.073, emacs, jasonr, juri, zedek,
emacs-devel, drew.adams
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]
2005-12-08 19:27 ` Richard M. Stallman
@ 2005-12-08 20:34 ` Lőrentey Károly
2005-12-09 15:04 ` Richard M. Stallman
2005-12-08 21:27 ` Michael Kifer
1 sibling, 1 reply; 1364+ messages in thread
From: Lőrentey Károly @ 2005-12-08 20:34 UTC (permalink / raw
Cc: Richard Stallman
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]
2005-12-08 19:27 ` Richard M. Stallman
2005-12-08 20:34 ` Lőrentey Károly
@ 2005-12-08 21:27 ` Michael Kifer
1 sibling, 0 replies; 1364+ messages in thread
From: Michael Kifer @ 2005-12-08 21:27 UTC (permalink / raw
Cc: emacs-devel, evilborisnet
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?
>
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 19:27 ` Richard M. Stallman
@ 2005-12-08 21:34 ` Peter Whaite
2005-12-09 15:02 ` Richard M. Stallman
2005-12-09 15:02 ` Richard M. Stallman
2005-12-09 2:25 ` Luc Teirlinck
1 sibling, 2 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-08 21:34 UTC (permalink / raw
Cc: lennart.borgman.073, teirllm, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 0:39 ` Lennart Borgman
@ 2005-12-08 21:54 ` Peter Whaite
0 siblings, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-08 21:54 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 2:30 ` Luc Teirlinck
@ 2005-12-08 21:57 ` Juri Linkov
2005-12-09 0:57 ` Luc Teirlinck
2005-12-09 1:27 ` unexec and fedora core 4 Camm Maguire
0 siblings, 2 replies; 1364+ messages in thread
From: Juri Linkov @ 2005-12-08 21:57 UTC (permalink / raw
Cc: emacs-devel
> 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/
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 21:57 ` Juri Linkov
@ 2005-12-09 0:57 ` Luc Teirlinck
2005-12-09 1:08 ` Lennart Borgman
2005-12-09 1:27 ` unexec and fedora core 4 Camm Maguire
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-09 0:57 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 0:57 ` Luc Teirlinck
@ 2005-12-09 1:08 ` Lennart Borgman
2005-12-09 1:30 ` Luc Teirlinck
2005-12-09 15:04 ` Richard M. Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-09 1:08 UTC (permalink / raw
Cc: juri, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* unexec and fedora core 4
2005-12-08 21:57 ` Juri Linkov
2005-12-09 0:57 ` Luc Teirlinck
@ 2005-12-09 1:27 ` Camm Maguire
2005-12-09 15:04 ` Richard M. Stallman
[not found] ` <slrndpilut.ha3.jsnell@dogbert.localdomain>
1 sibling, 2 replies; 1364+ messages in thread
From: Camm Maguire @ 2005-12-09 1:27 UTC (permalink / raw
Cc: Matt Kaufmann, gcl-devel, Sandip Ray
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 1:08 ` Lennart Borgman
@ 2005-12-09 1:30 ` Luc Teirlinck
2005-12-09 17:32 ` Peter Whaite
2005-12-09 15:04 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-09 1:30 UTC (permalink / raw
Cc: juri, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 19:27 ` Richard M. Stallman
2005-12-08 21:34 ` Peter Whaite
@ 2005-12-09 2:25 ` Luc Teirlinck
2005-12-09 17:30 ` Lennart Borgman
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-09 2:25 UTC (permalink / raw
Cc: lennart.borgman.073, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* newsticker-start: Recursive laod error
@ 2005-12-09 8:34 Sascha Wilde
2005-12-10 8:55 ` Xavier Maillard
2005-12-11 11:40 ` Romain Francoise
0 siblings, 2 replies; 1364+ messages in thread
From: Sascha Wilde @ 2005-12-09 8:34 UTC (permalink / raw
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
--
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 21:34 ` Peter Whaite
@ 2005-12-09 15:02 ` Richard M. Stallman
2005-12-09 15:02 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-09 15:02 UTC (permalink / raw
Cc: lennart.borgman.073, teirllm, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-08 21:34 ` Peter Whaite
2005-12-09 15:02 ` Richard M. Stallman
@ 2005-12-09 15:02 ` Richard M. Stallman
2005-12-09 17:40 ` Lennart Borgman
1 sibling, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-09 15:02 UTC (permalink / raw
Cc: lennart.borgman.073, teirllm, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 1:08 ` Lennart Borgman
2005-12-09 1:30 ` Luc Teirlinck
@ 2005-12-09 15:04 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-09 15:04 UTC (permalink / raw
Cc: juri, teirllm, emacs-devel
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: unexec and fedora core 4
2005-12-09 1:27 ` unexec and fedora core 4 Camm Maguire
@ 2005-12-09 15:04 ` Richard M. Stallman
[not found] ` <slrndpilut.ha3.jsnell@dogbert.localdomain>
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-09 15:04 UTC (permalink / raw
Cc: kaufmann, sandip, gcl-devel, emacs-devel
How about asking some Fedora developers to help you?
(I don't know how to reach them.)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [evilborisnet@netscape.net: weird behavior of ediff with multiple displays]
2005-12-08 20:34 ` Lőrentey Károly
@ 2005-12-09 15:04 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-09 15:04 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Re: unexec and fedora core 4
[not found] ` <slrndpilut.ha3.jsnell@dogbert.localdomain>
@ 2005-12-09 15:17 ` Camm Maguire
2005-12-09 21:43 ` Camm Maguire
0 siblings, 1 reply; 1364+ messages in thread
From: Camm Maguire @ 2005-12-09 15:17 UTC (permalink / raw
Cc: Matt Kaufmann, Sandip Ray, gcl-devel, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 2:25 ` Luc Teirlinck
@ 2005-12-09 17:30 ` Lennart Borgman
2005-12-09 18:06 ` Peter Whaite
2005-12-09 21:15 ` Richard M. Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-09 17:30 UTC (permalink / raw
Cc: rms, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 1:30 ` Luc Teirlinck
@ 2005-12-09 17:32 ` Peter Whaite
2005-12-10 4:13 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-12-09 17:32 UTC (permalink / raw
Cc: juri, lennart.borgman.073, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 15:02 ` Richard M. Stallman
@ 2005-12-09 17:40 ` Lennart Borgman
2005-12-09 18:34 ` Peter Whaite
2005-12-10 4:14 ` Richard M. Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-09 17:40 UTC (permalink / raw
Cc: teirllm, Peter Whaite, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 23:52 ` Luc Teirlinck
@ 2005-12-09 17:42 ` Peter Whaite
0 siblings, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-09 17:42 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 17:07 ` fancy-splash-screen customize group Richard M. Stallman
@ 2005-12-09 17:49 ` Lennart Borgman
0 siblings, 0 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-09 17:49 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 2:25 ` Luc Teirlinck
2005-12-09 17:30 ` Lennart Borgman
@ 2005-12-09 18:06 ` Peter Whaite
2005-12-10 4:13 ` Richard M. Stallman
2005-12-09 21:15 ` Richard M. Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2005-12-09 18:06 UTC (permalink / raw
Cc: lennart.borgman.073, rms, emacs, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 17:40 ` Lennart Borgman
@ 2005-12-09 18:34 ` Peter Whaite
2005-12-10 4:14 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2005-12-09 18:34 UTC (permalink / raw
Cc: teirllm, rms, Peter Whaite, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 2:25 ` Luc Teirlinck
2005-12-09 17:30 ` Lennart Borgman
2005-12-09 18:06 ` Peter Whaite
@ 2005-12-09 21:15 ` Richard M. Stallman
2005-12-09 23:15 ` Luc Teirlinck
2 siblings, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-09 21:15 UTC (permalink / raw
Cc: lennart.borgman.073, emacs, emacs-devel
* 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Re: unexec and fedora core 4
2005-12-09 15:17 ` Camm Maguire
@ 2005-12-09 21:43 ` Camm Maguire
2005-12-10 9:20 ` [Gcl-devel] " Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Camm Maguire @ 2005-12-09 21:43 UTC (permalink / raw
Cc: gcl-devel, emacs-devel, root, Matt Kaufmann, axiom-developer,
Sandip Ray
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 21:15 ` Richard M. Stallman
@ 2005-12-09 23:15 ` Luc Teirlinck
2005-12-10 16:18 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-09 23:15 UTC (permalink / raw
Cc: lennart.borgman.073, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-04 21:18 ` Richard M. Stallman
2005-12-04 21:22 ` David Kastrup
@ 2005-12-10 4:07 ` Luc Teirlinck
2005-12-10 16:19 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-10 4:07 UTC (permalink / raw
Cc: romain, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 18:06 ` Peter Whaite
@ 2005-12-10 4:13 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-10 4:13 UTC (permalink / raw
Cc: lennart.borgman.073, teirllm, emacs, emacs-devel
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))))
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 17:32 ` Peter Whaite
@ 2005-12-10 4:13 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-10 4:13 UTC (permalink / raw
Cc: juri, lennart.borgman.073, teirllm, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 17:40 ` Lennart Borgman
2005-12-09 18:34 ` Peter Whaite
@ 2005-12-10 4:14 ` Richard M. Stallman
2005-12-10 14:38 ` Lennart Borgman
1 sibling, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-10 4:14 UTC (permalink / raw
Cc: teirllm, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-09 8:34 newsticker-start: Recursive laod error Sascha Wilde
@ 2005-12-10 8:55 ` Xavier Maillard
2005-12-10 10:38 ` Lennart Borgman
2005-12-10 10:44 ` Eli Zaretskii
2005-12-11 11:40 ` Romain Francoise
1 sibling, 2 replies; 1364+ messages in thread
From: Xavier Maillard @ 2005-12-10 8:55 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [Gcl-devel] Re: unexec and fedora core 4
2005-12-09 21:43 ` Camm Maguire
@ 2005-12-10 9:20 ` Eli Zaretskii
2005-12-13 3:15 ` Camm Maguire
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2005-12-10 9:20 UTC (permalink / raw
Cc: gcl-devel, emacs-devel, daly, kaufmann, axiom-developer, jsnell,
sandip
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-10 8:55 ` Xavier Maillard
@ 2005-12-10 10:38 ` Lennart Borgman
2005-12-10 14:12 ` Robert J. Chassell
2005-12-11 5:02 ` Richard M. Stallman
2005-12-10 10:44 ` Eli Zaretskii
1 sibling, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-10 10:38 UTC (permalink / raw
Cc: Sascha Wilde, emacs-devel
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"
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-10 8:55 ` Xavier Maillard
2005-12-10 10:38 ` Lennart Borgman
@ 2005-12-10 10:44 ` Eli Zaretskii
[not found] ` <eliz@gnu.org>
2005-12-11 0:25 ` Xavier Maillard
1 sibling, 2 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2005-12-10 10:44 UTC (permalink / raw
Cc: wilde, emacs-devel
> 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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-10 10:38 ` Lennart Borgman
@ 2005-12-10 14:12 ` Robert J. Chassell
2005-12-11 5:02 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Robert J. Chassell @ 2005-12-10 14:12 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
[not found] ` <eliz@gnu.org>
@ 2005-12-10 14:28 ` Ulf Jasper
2005-12-10 19:32 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Ulf Jasper @ 2005-12-10 14:28 UTC (permalink / raw
Cc: zedek, wilde, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-10 4:14 ` Richard M. Stallman
@ 2005-12-10 14:38 ` Lennart Borgman
2005-12-10 15:21 ` Luc Teirlinck
2005-12-11 5:03 ` Richard M. Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-10 14:38 UTC (permalink / raw
Cc: teirllm, emacs, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-10 14:38 ` Lennart Borgman
@ 2005-12-10 15:21 ` Luc Teirlinck
2005-12-10 19:29 ` Lennart Borgman
2005-12-11 5:03 ` Richard M. Stallman
2005-12-11 5:03 ` Richard M. Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-10 15:21 UTC (permalink / raw
Cc: rms, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-09 23:15 ` Luc Teirlinck
@ 2005-12-10 16:18 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-10 16:18 UTC (permalink / raw
Cc: lennart.borgman.073, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-10 4:07 ` Luc Teirlinck
@ 2005-12-10 16:19 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-10 16:19 UTC (permalink / raw
Cc: romain, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-10 15:21 ` Luc Teirlinck
@ 2005-12-10 19:29 ` Lennart Borgman
2005-12-11 3:40 ` Luc Teirlinck
2005-12-11 22:57 ` Richard M. Stallman
2005-12-11 5:03 ` Richard M. Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-10 19:29 UTC (permalink / raw
Cc: rms, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-10 14:28 ` Ulf Jasper
@ 2005-12-10 19:32 ` Eli Zaretskii
2005-12-10 19:59 ` Lennart Borgman
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2005-12-10 19:32 UTC (permalink / raw
Cc: zedek, wilde, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-10 19:32 ` Eli Zaretskii
@ 2005-12-10 19:59 ` Lennart Borgman
2005-12-11 16:49 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-10 19:59 UTC (permalink / raw
Cc: ulf.jasper, zedek, wilde, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-10 10:44 ` Eli Zaretskii
[not found] ` <eliz@gnu.org>
@ 2005-12-11 0:25 ` Xavier Maillard
1 sibling, 0 replies; 1364+ messages in thread
From: Xavier Maillard @ 2005-12-11 0:25 UTC (permalink / raw
Cc: wilde, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-10 19:29 ` Lennart Borgman
@ 2005-12-11 3:40 ` Luc Teirlinck
2005-12-11 18:55 ` Drew Adams
2005-12-11 22:57 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-11 3:40 UTC (permalink / raw
Cc: rms, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-10 10:38 ` Lennart Borgman
2005-12-10 14:12 ` Robert J. Chassell
@ 2005-12-11 5:02 ` Richard M. Stallman
2005-12-11 8:51 ` Xavier Maillard
1 sibling, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 5:02 UTC (permalink / raw
Cc: zedek, wilde, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-10 15:21 ` Luc Teirlinck
2005-12-10 19:29 ` Lennart Borgman
@ 2005-12-11 5:03 ` Richard M. Stallman
2005-12-11 6:23 ` Luc Teirlinck
1 sibling, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 5:03 UTC (permalink / raw
Cc: lennart.borgman.073, emacs, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-10 14:38 ` Lennart Borgman
2005-12-10 15:21 ` Luc Teirlinck
@ 2005-12-11 5:03 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 5:03 UTC (permalink / raw
Cc: teirllm, emacs, emacs-devel
Your latest patch is ok, but it has problems of Texinfo usage.
Would someone like to correct the style?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-11 5:03 ` Richard M. Stallman
@ 2005-12-11 6:23 ` Luc Teirlinck
2005-12-11 22:26 ` Lennart Borgman
2005-12-11 22:56 ` Richard M. Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-11 6:23 UTC (permalink / raw
Cc: lennart.borgman.073, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-11 5:02 ` Richard M. Stallman
@ 2005-12-11 8:51 ` Xavier Maillard
2005-12-11 22:56 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Xavier Maillard @ 2005-12-11 8:51 UTC (permalink / raw
Cc: wilde, lennart.borgman.073, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-09 8:34 newsticker-start: Recursive laod error Sascha Wilde
2005-12-10 8:55 ` Xavier Maillard
@ 2005-12-11 11:40 ` Romain Francoise
[not found] ` <romain@orebokech.com>
1 sibling, 1 reply; 1364+ messages in thread
From: Romain Francoise @ 2005-12-11 11:40 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-10 19:59 ` Lennart Borgman
@ 2005-12-11 16:49 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 16:49 UTC (permalink / raw
Cc: ulf.jasper, zedek, eliz, wilde, emacs-devel
>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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: fancy-splash-screen customize group...
2005-12-11 3:40 ` Luc Teirlinck
@ 2005-12-11 18:55 ` Drew Adams
2005-12-12 4:55 ` Luc Teirlinck
2005-12-12 5:24 ` Richard M. Stallman
0 siblings, 2 replies; 1364+ messages in thread
From: Drew Adams @ 2005-12-11 18:55 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-11 6:23 ` Luc Teirlinck
@ 2005-12-11 22:26 ` Lennart Borgman
2005-12-12 4:48 ` Luc Teirlinck
2005-12-11 22:56 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-11 22:26 UTC (permalink / raw
Cc: rms, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-11 6:23 ` Luc Teirlinck
2005-12-11 22:26 ` Lennart Borgman
@ 2005-12-11 22:56 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 22:56 UTC (permalink / raw
Cc: lennart.borgman.073, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-11 8:51 ` Xavier Maillard
@ 2005-12-11 22:56 ` Richard M. Stallman
2005-12-12 21:00 ` Xavier Maillard
2005-12-14 9:24 ` Sascha Wilde
0 siblings, 2 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 22:56 UTC (permalink / raw
Cc: wilde, lennart.borgman.073, emacs-devel
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 ----
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 18:26 ` Peter Whaite
@ 2005-12-11 22:57 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 22:57 UTC (permalink / raw
Cc: zedek, cyd, drew.adams, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-07 22:38 ` Lennart Borgman
` (2 preceding siblings ...)
[not found] ` <200512072321.jB7NLMR03715@raven.dms.auburn.edu>
@ 2005-12-11 22:57 ` Richard M. Stallman
2005-12-13 1:27 ` Lennart Borgman
3 siblings, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 22:57 UTC (permalink / raw
Cc: teirllm, abraham, cyd, emacs, jasonr, juri, zedek, emacs-devel,
drew.adams
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-10 19:29 ` Lennart Borgman
2005-12-11 3:40 ` Luc Teirlinck
@ 2005-12-11 22:57 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-11 22:57 UTC (permalink / raw
Cc: teirllm, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-11 22:26 ` Lennart Borgman
@ 2005-12-12 4:48 ` Luc Teirlinck
0 siblings, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-12 4:48 UTC (permalink / raw
Cc: rms, emacs, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-11 18:55 ` Drew Adams
@ 2005-12-12 4:55 ` Luc Teirlinck
2005-12-12 5:24 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-12 4:55 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-11 18:55 ` Drew Adams
2005-12-12 4:55 ` Luc Teirlinck
@ 2005-12-12 5:24 ` Richard M. Stallman
2005-12-12 5:40 ` Drew Adams
2005-12-13 3:50 ` Luc Teirlinck
1 sibling, 2 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-12 5:24 UTC (permalink / raw
Cc: emacs-devel
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.)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: fancy-splash-screen customize group...
2005-12-12 5:24 ` Richard M. Stallman
@ 2005-12-12 5:40 ` Drew Adams
2005-12-13 3:50 ` Luc Teirlinck
1 sibling, 0 replies; 1364+ messages in thread
From: Drew Adams @ 2005-12-12 5:40 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
[not found] ` <romain@orebokech.com>
@ 2005-12-12 18:39 ` Ulf Jasper
2005-12-12 22:00 ` Thien-Thi Nguyen
0 siblings, 1 reply; 1364+ messages in thread
From: Ulf Jasper @ 2005-12-12 18:39 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-11 22:56 ` Richard M. Stallman
@ 2005-12-12 21:00 ` Xavier Maillard
2005-12-14 9:24 ` Sascha Wilde
1 sibling, 0 replies; 1364+ messages in thread
From: Xavier Maillard @ 2005-12-12 21:00 UTC (permalink / raw
Cc: wilde, lennart.borgman.073, emacs-devel
Thanks for investigating. Does this fix it?
That works beautifuly for me.
Thank you
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-12 18:39 ` Ulf Jasper
@ 2005-12-12 22:00 ` Thien-Thi Nguyen
2005-12-12 23:36 ` Thien-Thi Nguyen
0 siblings, 1 reply; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2005-12-12 22:00 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-12 22:00 ` Thien-Thi Nguyen
@ 2005-12-12 23:36 ` Thien-Thi Nguyen
2005-12-13 15:54 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2005-12-12 23:36 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-11 22:57 ` Richard M. Stallman
@ 2005-12-13 1:27 ` Lennart Borgman
2005-12-13 23:33 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-13 1:27 UTC (permalink / raw
Cc: teirllm, abraham, cyd, emacs, jasonr, juri, zedek, emacs-devel,
drew.adams
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: [Gcl-devel] Re: unexec and fedora core 4
2005-12-10 9:20 ` [Gcl-devel] " Eli Zaretskii
@ 2005-12-13 3:15 ` Camm Maguire
0 siblings, 0 replies; 1364+ messages in thread
From: Camm Maguire @ 2005-12-13 3:15 UTC (permalink / raw
Cc: gcl-devel, emacs-devel, kaufmann, axiom-developer, jsnell, sandip
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-12 5:24 ` Richard M. Stallman
2005-12-12 5:40 ` Drew Adams
@ 2005-12-13 3:50 ` Luc Teirlinck
2005-12-13 23:33 ` Richard M. Stallman
1 sibling, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2005-12-13 3:50 UTC (permalink / raw
Cc: drew.adams, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-12 23:36 ` Thien-Thi Nguyen
@ 2005-12-13 15:54 ` Stefan Monnier
2005-12-13 21:08 ` Thien-Thi Nguyen
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2005-12-13 15:54 UTC (permalink / raw
Cc: ulf.jasper, emacs-devel
> sorry, this is wrong. it should read:
> (< 0 (length LIST)) === LIST
Unless LIST is a string, of course,
Stefan
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-13 15:54 ` Stefan Monnier
@ 2005-12-13 21:08 ` Thien-Thi Nguyen
2005-12-13 21:40 ` Stefan Monnier
0 siblings, 1 reply; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2005-12-13 21:08 UTC (permalink / raw
Cc: ulf.jasper, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-13 21:08 ` Thien-Thi Nguyen
@ 2005-12-13 21:40 ` Stefan Monnier
[not found] ` <monnier@iro.umontreal.ca>
0 siblings, 1 reply; 1364+ messages in thread
From: Stefan Monnier @ 2005-12-13 21:40 UTC (permalink / raw
Cc: ulf.jasper, emacs-devel
>> > (< 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-13 1:27 ` Lennart Borgman
@ 2005-12-13 23:33 ` Richard M. Stallman
2005-12-19 16:04 ` Lennart Borgman
0 siblings, 1 reply; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-13 23:33 UTC (permalink / raw
Cc: teirllm, abraham, cyd, emacs, jasonr, juri, zedek, emacs-devel,
drew.adams
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-13 3:50 ` Luc Teirlinck
@ 2005-12-13 23:33 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-13 23:33 UTC (permalink / raw
Cc: drew.adams, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-11 22:56 ` Richard M. Stallman
2005-12-12 21:00 ` Xavier Maillard
@ 2005-12-14 9:24 ` Sascha Wilde
2005-12-14 15:35 ` Lennart Borgman
2005-12-15 15:11 ` Sascha Wilde
1 sibling, 2 replies; 1364+ messages in thread
From: Sascha Wilde @ 2005-12-14 9:24 UTC (permalink / raw
Cc: zedek, lennart.borgman.073, emacs-devel
"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...
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-14 9:24 ` Sascha Wilde
@ 2005-12-14 15:35 ` Lennart Borgman
2005-12-14 15:43 ` Sascha Wilde
2005-12-15 17:13 ` Xavier Maillard
2005-12-15 15:11 ` Sascha Wilde
1 sibling, 2 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-14 15:35 UTC (permalink / raw
Cc: zedek, rms, emacs-devel
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?
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-14 15:35 ` Lennart Borgman
@ 2005-12-14 15:43 ` Sascha Wilde
2005-12-15 17:13 ` Xavier Maillard
1 sibling, 0 replies; 1364+ messages in thread
From: Sascha Wilde @ 2005-12-14 15:43 UTC (permalink / raw
Cc: zedek, rms, emacs-devel
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
--
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
[not found] ` <monnier@iro.umontreal.ca>
@ 2005-12-14 19:22 ` Ulf Jasper
2005-12-14 22:16 ` Tomas Zerolo
2005-12-15 0:35 ` Thien-Thi Nguyen
0 siblings, 2 replies; 1364+ messages in thread
From: Ulf Jasper @ 2005-12-14 19:22 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-14 19:22 ` Ulf Jasper
@ 2005-12-14 22:16 ` Tomas Zerolo
2005-12-15 0:35 ` Thien-Thi Nguyen
1 sibling, 0 replies; 1364+ messages in thread
From: Tomas Zerolo @ 2005-12-14 22:16 UTC (permalink / raw
Cc: Thien-Thi Nguyen, Stefan Monnier, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-14 19:22 ` Ulf Jasper
2005-12-14 22:16 ` Tomas Zerolo
@ 2005-12-15 0:35 ` Thien-Thi Nguyen
2005-12-15 1:51 ` Drew Adams
[not found] ` <ttn@gnu.org>
1 sibling, 2 replies; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2005-12-15 0:35 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: newsticker-start: Recursive laod error
2005-12-15 0:35 ` Thien-Thi Nguyen
@ 2005-12-15 1:51 ` Drew Adams
[not found] ` <ttn@gnu.org>
1 sibling, 0 replies; 1364+ messages in thread
From: Drew Adams @ 2005-12-15 1:51 UTC (permalink / raw
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...
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-14 9:24 ` Sascha Wilde
2005-12-14 15:35 ` Lennart Borgman
@ 2005-12-15 15:11 ` Sascha Wilde
2005-12-15 15:53 ` Lennart Borgman
2005-12-16 1:52 ` Richard M. Stallman
1 sibling, 2 replies; 1364+ messages in thread
From: Sascha Wilde @ 2005-12-15 15:11 UTC (permalink / raw
Cc: zedek, lennart.borgman.073, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-15 15:11 ` Sascha Wilde
@ 2005-12-15 15:53 ` Lennart Borgman
2005-12-16 1:52 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-15 15:53 UTC (permalink / raw
Cc: zedek, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-14 15:35 ` Lennart Borgman
2005-12-14 15:43 ` Sascha Wilde
@ 2005-12-15 17:13 ` Xavier Maillard
2005-12-15 17:28 ` Lennart Borgman
1 sibling, 1 reply; 1364+ messages in thread
From: Xavier Maillard @ 2005-12-15 17:13 UTC (permalink / raw
Cc: wilde, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-15 17:13 ` Xavier Maillard
@ 2005-12-15 17:28 ` Lennart Borgman
2005-12-15 19:47 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-15 17:28 UTC (permalink / raw
Cc: emacs-devel
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.)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-15 17:28 ` Lennart Borgman
@ 2005-12-15 19:47 ` Eli Zaretskii
0 siblings, 0 replies; 1364+ messages in thread
From: Eli Zaretskii @ 2005-12-15 19:47 UTC (permalink / raw
Cc: zedek, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
[not found] ` <ttn@gnu.org>
@ 2005-12-15 20:18 ` Ulf Jasper
0 siblings, 0 replies; 1364+ messages in thread
From: Ulf Jasper @ 2005-12-15 20:18 UTC (permalink / raw
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 ----
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: newsticker-start: Recursive laod error
2005-12-15 15:11 ` Sascha Wilde
2005-12-15 15:53 ` Lennart Borgman
@ 2005-12-16 1:52 ` Richard M. Stallman
1 sibling, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-16 1:52 UTC (permalink / raw
Cc: zedek, lennart.borgman.073, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-13 23:33 ` Richard M. Stallman
@ 2005-12-19 16:04 ` Lennart Borgman
2005-12-20 16:33 ` Richard M. Stallman
0 siblings, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2005-12-19 16:04 UTC (permalink / raw
Cc: juri, abraham, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: fancy-splash-screen customize group...
2005-12-19 16:04 ` Lennart Borgman
@ 2005-12-20 16:33 ` Richard M. Stallman
0 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2005-12-20 16:33 UTC (permalink / raw
Cc: juri, abraham, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Documentation for car and cdr
@ 2006-01-24 16:55 Mario Domenech Goulart
2006-01-24 22:30 ` Kevin Rodgers
2006-01-24 23:14 ` David Kastrup
0 siblings, 2 replies; 1364+ messages in thread
From: Mario Domenech Goulart @ 2006-01-24 16:55 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-24 22:30 ` Kevin Rodgers
@ 2006-01-24 21:45 ` Mario Domenech Goulart
0 siblings, 0 replies; 1364+ messages in thread
From: Mario Domenech Goulart @ 2006-01-24 21:45 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-24 16:55 Documentation for car and cdr Mario Domenech Goulart
@ 2006-01-24 22:30 ` Kevin Rodgers
2006-01-24 21:45 ` Mario Domenech Goulart
2006-01-24 23:14 ` David Kastrup
1 sibling, 1 reply; 1364+ messages in thread
From: Kevin Rodgers @ 2006-01-24 22:30 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-24 16:55 Documentation for car and cdr Mario Domenech Goulart
2006-01-24 22:30 ` Kevin Rodgers
@ 2006-01-24 23:14 ` David Kastrup
2006-01-25 8:37 ` Mario Domenech Goulart
` (2 more replies)
1 sibling, 3 replies; 1364+ messages in thread
From: David Kastrup @ 2006-01-24 23:14 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-24 23:14 ` David Kastrup
@ 2006-01-25 8:37 ` Mario Domenech Goulart
2006-01-25 11:07 ` David Kastrup
2006-01-25 15:44 ` Richard M. Stallman
2006-01-25 19:54 ` Alan Mackenzie
2 siblings, 1 reply; 1364+ messages in thread
From: Mario Domenech Goulart @ 2006-01-25 8:37 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 8:37 ` Mario Domenech Goulart
@ 2006-01-25 11:07 ` David Kastrup
2006-01-25 12:42 ` Andreas Schwab
0 siblings, 1 reply; 1364+ messages in thread
From: David Kastrup @ 2006-01-25 11:07 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 11:07 ` David Kastrup
@ 2006-01-25 12:42 ` Andreas Schwab
2006-01-25 12:47 ` David Kastrup
0 siblings, 1 reply; 1364+ messages in thread
From: Andreas Schwab @ 2006-01-25 12:42 UTC (permalink / raw
Cc: Mario Domenech Goulart, emacs-devel
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."
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 12:42 ` Andreas Schwab
@ 2006-01-25 12:47 ` David Kastrup
0 siblings, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2006-01-25 12:47 UTC (permalink / raw
Cc: Mario Domenech Goulart, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-24 23:14 ` David Kastrup
2006-01-25 8:37 ` Mario Domenech Goulart
@ 2006-01-25 15:44 ` Richard M. Stallman
2006-01-25 19:54 ` Alan Mackenzie
2 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2006-01-25 15:44 UTC (permalink / raw
Cc: mario.goulart, emacs-devel
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-24 23:14 ` David Kastrup
2006-01-25 8:37 ` Mario Domenech Goulart
2006-01-25 15:44 ` Richard M. Stallman
@ 2006-01-25 19:54 ` Alan Mackenzie
2006-01-25 21:43 ` Bill Atkins
` (4 more replies)
2 siblings, 5 replies; 1364+ messages in thread
From: Alan Mackenzie @ 2006-01-25 19:54 UTC (permalink / raw
Cc: Mario Domenech Goulart, emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 21:43 ` Bill Atkins
@ 2006-01-25 21:41 ` Alan Mackenzie
2006-01-25 23:19 ` Bill Atkins
` (4 more replies)
0 siblings, 5 replies; 1364+ messages in thread
From: Alan Mackenzie @ 2006-01-25 21:41 UTC (permalink / raw
Cc: emacs-devel
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)
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 19:54 ` Alan Mackenzie
@ 2006-01-25 21:43 ` Bill Atkins
2006-01-25 21:41 ` Alan Mackenzie
2006-01-25 21:44 ` Lennart Borgman
` (3 subsequent siblings)
4 siblings, 1 reply; 1364+ messages in thread
From: Bill Atkins @ 2006-01-25 21:43 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 19:54 ` Alan Mackenzie
2006-01-25 21:43 ` Bill Atkins
@ 2006-01-25 21:44 ` Lennart Borgman
2006-01-25 22:01 ` Alfred M. Szmidt
` (2 subsequent siblings)
4 siblings, 0 replies; 1364+ messages in thread
From: Lennart Borgman @ 2006-01-25 21:44 UTC (permalink / raw
Cc: Mario Domenech Goulart, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 19:54 ` Alan Mackenzie
2006-01-25 21:43 ` Bill Atkins
2006-01-25 21:44 ` Lennart Borgman
@ 2006-01-25 22:01 ` Alfred M. Szmidt
2006-01-25 22:07 ` Thien-Thi Nguyen
2006-01-25 22:11 ` Luc Teirlinck
4 siblings, 0 replies; 1364+ messages in thread
From: Alfred M. Szmidt @ 2006-01-25 22:01 UTC (permalink / raw
Cc: mario.goulart, emacs-devel
>> ,----[ 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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 19:54 ` Alan Mackenzie
` (2 preceding siblings ...)
2006-01-25 22:01 ` Alfred M. Szmidt
@ 2006-01-25 22:07 ` Thien-Thi Nguyen
2006-01-25 22:16 ` Alan Mackenzie
2006-01-25 22:11 ` Luc Teirlinck
4 siblings, 1 reply; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2006-01-25 22:07 UTC (permalink / raw
Cc: Mario Domenech Goulart, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 19:54 ` Alan Mackenzie
` (3 preceding siblings ...)
2006-01-25 22:07 ` Thien-Thi Nguyen
@ 2006-01-25 22:11 ` Luc Teirlinck
2006-01-25 22:35 ` Alan Mackenzie
` (2 more replies)
4 siblings, 3 replies; 1364+ messages in thread
From: Luc Teirlinck @ 2006-01-25 22:11 UTC (permalink / raw
Cc: mario.goulart, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:07 ` Thien-Thi Nguyen
@ 2006-01-25 22:16 ` Alan Mackenzie
2006-01-26 0:04 ` Karl Chen
2006-01-26 0:38 ` Thien-Thi Nguyen
0 siblings, 2 replies; 1364+ messages in thread
From: Alan Mackenzie @ 2006-01-25 22:16 UTC (permalink / raw
Cc: Mario Domenech Goulart, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:11 ` Luc Teirlinck
@ 2006-01-25 22:35 ` Alan Mackenzie
2006-01-26 13:25 ` Tomas Zerolo
2006-01-25 22:51 ` Kim F. Storm
2006-01-26 17:46 ` Richard M. Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Alan Mackenzie @ 2006-01-25 22:35 UTC (permalink / raw
Cc: mario.goulart, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:11 ` Luc Teirlinck
2006-01-25 22:35 ` Alan Mackenzie
@ 2006-01-25 22:51 ` Kim F. Storm
2006-01-25 23:31 ` Peter Whaite
` (2 more replies)
2006-01-26 17:46 ` Richard M. Stallman
2 siblings, 3 replies; 1364+ messages in thread
From: Kim F. Storm @ 2006-01-25 22:51 UTC (permalink / raw
Cc: acm, mario.goulart, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 21:41 ` Alan Mackenzie
@ 2006-01-25 23:19 ` Bill Atkins
2006-01-25 23:29 ` David Kastrup
` (3 subsequent siblings)
4 siblings, 0 replies; 1364+ messages in thread
From: Bill Atkins @ 2006-01-25 23:19 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 21:41 ` Alan Mackenzie
2006-01-25 23:19 ` Bill Atkins
@ 2006-01-25 23:29 ` David Kastrup
2006-01-26 0:25 ` Thien-Thi Nguyen
` (2 subsequent siblings)
4 siblings, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2006-01-25 23:29 UTC (permalink / raw
Cc: Bill Atkins, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:51 ` Kim F. Storm
@ 2006-01-25 23:31 ` Peter Whaite
2006-01-25 23:36 ` David Kastrup
2006-01-25 23:49 ` Mario Domenech Goulart
2006-01-26 17:46 ` Richard M. Stallman
2 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2006-01-25 23:31 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 23:31 ` Peter Whaite
@ 2006-01-25 23:36 ` David Kastrup
0 siblings, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2006-01-25 23:36 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:51 ` Kim F. Storm
2006-01-25 23:31 ` Peter Whaite
@ 2006-01-25 23:49 ` Mario Domenech Goulart
2006-01-26 17:46 ` Richard M. Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Mario Domenech Goulart @ 2006-01-25 23:49 UTC (permalink / raw
Cc: acm, Luc Teirlinck, emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:16 ` Alan Mackenzie
@ 2006-01-26 0:04 ` Karl Chen
2006-01-26 0:18 ` Luc Teirlinck
2006-01-26 0:38 ` Thien-Thi Nguyen
1 sibling, 1 reply; 1364+ messages in thread
From: Karl Chen @ 2006-01-26 0:04 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 0:04 ` Karl Chen
@ 2006-01-26 0:18 ` Luc Teirlinck
2006-01-26 4:33 ` Eli Zaretskii
0 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2006-01-26 0:18 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 21:41 ` Alan Mackenzie
2006-01-25 23:19 ` Bill Atkins
2006-01-25 23:29 ` David Kastrup
@ 2006-01-26 0:25 ` Thien-Thi Nguyen
2006-01-26 0:33 ` Lennart Borgman
2006-01-26 17:12 ` Drew Adams
2006-01-26 1:54 ` Miles Bader
2006-01-26 1:54 ` Miles Bader
4 siblings, 2 replies; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2006-01-26 0:25 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 0:25 ` Thien-Thi Nguyen
@ 2006-01-26 0:33 ` Lennart Borgman
2006-01-26 1:04 ` Thien-Thi Nguyen
2006-01-26 17:12 ` Drew Adams
1 sibling, 1 reply; 1364+ messages in thread
From: Lennart Borgman @ 2006-01-26 0:33 UTC (permalink / raw
Cc: Alan Mackenzie, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:16 ` Alan Mackenzie
2006-01-26 0:04 ` Karl Chen
@ 2006-01-26 0:38 ` Thien-Thi Nguyen
2006-01-26 9:34 ` Alan Mackenzie
1 sibling, 1 reply; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2006-01-26 0:38 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 0:33 ` Lennart Borgman
@ 2006-01-26 1:04 ` Thien-Thi Nguyen
2006-01-26 17:21 ` Drew Adams
0 siblings, 1 reply; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2006-01-26 1:04 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 21:41 ` Alan Mackenzie
` (2 preceding siblings ...)
2006-01-26 0:25 ` Thien-Thi Nguyen
@ 2006-01-26 1:54 ` Miles Bader
2006-01-26 1:54 ` Miles Bader
4 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2006-01-26 1:54 UTC (permalink / raw
Cc: Bill Atkins, emacs-devel
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 21:41 ` Alan Mackenzie
` (3 preceding siblings ...)
2006-01-26 1:54 ` Miles Bader
@ 2006-01-26 1:54 ` Miles Bader
4 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2006-01-26 1:54 UTC (permalink / raw
Cc: Bill Atkins, emacs-devel
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!
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 0:18 ` Luc Teirlinck
@ 2006-01-26 4:33 ` Eli Zaretskii
2006-01-26 6:34 ` Miles Bader
0 siblings, 1 reply; 1364+ messages in thread
From: Eli Zaretskii @ 2006-01-26 4:33 UTC (permalink / raw
Cc: quarl+dated+1138665503.df20ee, emacs-devel
> 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).
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 4:33 ` Eli Zaretskii
@ 2006-01-26 6:34 ` Miles Bader
0 siblings, 0 replies; 1364+ messages in thread
From: Miles Bader @ 2006-01-26 6:34 UTC (permalink / raw
Cc: Luc Teirlinck, quarl+dated+1138665503.df20ee, emacs-devel
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]
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 0:38 ` Thien-Thi Nguyen
@ 2006-01-26 9:34 ` Alan Mackenzie
2006-01-26 13:28 ` Tomas Zerolo
2006-01-26 13:34 ` Thien-Thi Nguyen
0 siblings, 2 replies; 1364+ messages in thread
From: Alan Mackenzie @ 2006-01-26 9:34 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:35 ` Alan Mackenzie
@ 2006-01-26 13:25 ` Tomas Zerolo
0 siblings, 0 replies; 1364+ messages in thread
From: Tomas Zerolo @ 2006-01-26 13:25 UTC (permalink / raw
Cc: mario.goulart, Luc Teirlinck, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 9:34 ` Alan Mackenzie
@ 2006-01-26 13:28 ` Tomas Zerolo
2006-01-26 13:34 ` Thien-Thi Nguyen
1 sibling, 0 replies; 1364+ messages in thread
From: Tomas Zerolo @ 2006-01-26 13:28 UTC (permalink / raw
Cc: Thien-Thi Nguyen, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 9:34 ` Alan Mackenzie
2006-01-26 13:28 ` Tomas Zerolo
@ 2006-01-26 13:34 ` Thien-Thi Nguyen
1 sibling, 0 replies; 1364+ messages in thread
From: Thien-Thi Nguyen @ 2006-01-26 13:34 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: Documentation for car and cdr
2006-01-26 0:25 ` Thien-Thi Nguyen
2006-01-26 0:33 ` Lennart Borgman
@ 2006-01-26 17:12 ` Drew Adams
1 sibling, 0 replies; 1364+ messages in thread
From: Drew Adams @ 2006-01-26 17:12 UTC (permalink / raw
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* RE: Documentation for car and cdr
2006-01-26 1:04 ` Thien-Thi Nguyen
@ 2006-01-26 17:21 ` Drew Adams
0 siblings, 0 replies; 1364+ messages in thread
From: Drew Adams @ 2006-01-26 17:21 UTC (permalink / raw
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?(.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:11 ` Luc Teirlinck
2006-01-25 22:35 ` Alan Mackenzie
2006-01-25 22:51 ` Kim F. Storm
@ 2006-01-26 17:46 ` Richard M. Stallman
2 siblings, 0 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2006-01-26 17:46 UTC (permalink / raw
Cc: acm, mario.goulart, emacs-devel
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-25 22:51 ` Kim F. Storm
2006-01-25 23:31 ` Peter Whaite
2006-01-25 23:49 ` Mario Domenech Goulart
@ 2006-01-26 17:46 ` Richard M. Stallman
2006-01-26 18:09 ` Luc Teirlinck
` (2 more replies)
2 siblings, 3 replies; 1364+ messages in thread
From: Richard M. Stallman @ 2006-01-26 17:46 UTC (permalink / raw
Cc: acm, mario.goulart, teirllm, emacs-devel
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'.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 17:46 ` Richard M. Stallman
@ 2006-01-26 18:09 ` Luc Teirlinck
2006-01-26 19:55 ` Peter Whaite
2006-01-26 23:11 ` Jason Rumney
2006-01-26 23:53 ` David Kastrup
2 siblings, 1 reply; 1364+ messages in thread
From: Luc Teirlinck @ 2006-01-26 18:09 UTC (permalink / raw
Cc: acm, mario.goulart, emacs-devel, storm
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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 18:09 ` Luc Teirlinck
@ 2006-01-26 19:55 ` Peter Whaite
2006-01-26 22:17 ` Kevin Rodgers
0 siblings, 1 reply; 1364+ messages in thread
From: Peter Whaite @ 2006-01-26 19:55 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 19:55 ` Peter Whaite
@ 2006-01-26 22:17 ` Kevin Rodgers
2006-01-26 22:29 ` Jose E. Marchesi
2006-01-26 23:19 ` Peter Whaite
0 siblings, 2 replies; 1364+ messages in thread
From: Kevin Rodgers @ 2006-01-26 22:17 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 22:17 ` Kevin Rodgers
@ 2006-01-26 22:29 ` Jose E. Marchesi
2006-01-26 23:19 ` Peter Whaite
1 sibling, 0 replies; 1364+ messages in thread
From: Jose E. Marchesi @ 2006-01-26 22:29 UTC (permalink / raw
Cc: emacs-devel
+----+ +----+
| | | |
| 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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 17:46 ` Richard M. Stallman
2006-01-26 18:09 ` Luc Teirlinck
@ 2006-01-26 23:11 ` Jason Rumney
2006-01-26 23:53 ` David Kastrup
2 siblings, 0 replies; 1364+ messages in thread
From: Jason Rumney @ 2006-01-26 23:11 UTC (permalink / raw
Cc: acm, mario.goulart, emacs-devel, teirllm, Kim F. Storm
"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.
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 22:17 ` Kevin Rodgers
2006-01-26 22:29 ` Jose E. Marchesi
@ 2006-01-26 23:19 ` Peter Whaite
1 sibling, 0 replies; 1364+ messages in thread
From: Peter Whaite @ 2006-01-26 23:19 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 1364+ messages in thread
* Re: Documentation for car and cdr
2006-01-26 17:46 ` Richard M. Stallman
2006-01-26 18:09 ` Luc Teirlinck
2006-01-26 23:11 ` Jason Rumney
@ 2006-01-26 23:53 ` David Kastrup
2 siblings, 0 replies; 1364+ messages in thread
From: David Kastrup @ 2006-01-26 23:53 UTC (permalink / raw
Cc: acm, mario.goulart, emacs-devel, teirllm, Kim F. Storm
"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
^ permalink raw reply [flat|nested] 1364+ messages in thread
end of thread, other threads:[~2006-01-26 23:53 UTC | newest]
Thread overview: 1364+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <eliz@is.elta.co.il>
[not found] ` <8361-Fri22Mar2002162500+0200-eliz@is.elta.co.il>
2002-03-22 17:19 ` jit-lock-stealth-load Stephen Gildea
2002-03-24 6:13 ` jit-lock-stealth-load Eli Zaretskii
2002-03-24 15:53 ` jit-lock-stealth-load Richard Stallman
2002-03-25 2:10 ` jit-lock-stealth-load Stephen Gildea
2002-03-26 8:50 ` jit-lock-stealth-load Richard Stallman
2002-03-25 9:14 ` jit-lock-stealth-load Francesco Potorti`
[not found] <E16pNB6-0003ei-00@blackbird.home.nickwillson.com>
[not found] ` <87k7ran9bo.fsf@raven.i.defaultvalue.org>
[not found] ` <200204152200.g3FM0GD23812@aztec.santafe.edu>
[not found] ` <E16xK42-0001OV-00@blackbird.home.nickwillson.com>
[not found] ` <200204171603.g3HG3vw24750@aztec.santafe.edu>
[not found] ` <E16yQmB-0002oh-00@blackbird.home.nickwillson.com>
2002-04-19 18:43 ` Bug#139792: emacs21: Press PageDown, get infinite loop Richard Stallman
[not found] ` <rms@gnu.org>
2002-04-20 22:04 ` Nick
2003-01-05 8:12 ` Emacs crash in X Satyaki Das
2003-01-06 3:26 ` Richard Stallman
2003-01-06 9:07 ` Satyaki Das
[not found] ` <E194OUB-0006Mz-00@fencepost.gnu.org>
2003-04-13 14:41 ` [bob@rattlesnake.com: `whitespace-describe' function missing] Rajesh Vaidheeswarran
2003-10-20 22:27 ` RMAIL, MIME-related bug Peter S Galbraith
[not found] <E170n3M-0000tW-00@fencepost.gnu.org>
[not found] ` <1438-Thu25Apr2002222156+0300-eliz@is.elta.co.il>
2002-04-26 17:38 ` decode_eol and inconsistent EOL Richard Stallman
2002-04-26 18:26 ` Stephen Gildea
2002-04-26 19:22 ` Eli Zaretskii
2002-04-26 20:39 ` Stefan Monnier
2002-04-27 8:14 ` Eli Zaretskii
2002-04-28 22:40 ` Stefan Monnier
2002-04-29 4:54 ` Eli Zaretskii
2002-04-29 13:02 ` Stefan Monnier
2002-04-29 18:38 ` Eli Zaretskii
2002-04-30 5:19 ` Richard Stallman
2002-04-30 5:39 ` Eli Zaretskii
2002-04-28 21:17 ` Richard Stallman
2002-04-29 4:49 ` Eli Zaretskii
2002-04-29 5:37 ` Andrew Choi
2002-04-29 13:32 ` Stefan Monnier
2002-04-29 13:46 ` Andrew Choi
2002-04-30 5:18 ` Richard Stallman
2002-04-29 18:40 ` Richard Stallman
2002-04-29 19:13 ` Eli Zaretskii
2002-04-29 19:41 ` Stefan Monnier
2002-04-30 4:51 ` Eli Zaretskii
2002-04-30 21:19 ` Richard Stallman
2002-06-16 21:23 Integrate Tramp Kai Großjohann
2002-06-17 2:44 ` Miles Bader
2002-06-17 11:19 ` Kai Großjohann
2002-06-17 13:04 ` Miles Bader
2002-06-17 4:44 ` Eli Zaretskii
2002-06-17 11:20 ` Kai Großjohann
2002-06-17 16:31 ` Richard Stallman
2002-06-17 16:44 ` Kai Großjohann
2002-06-17 18:19 ` Eli Zaretskii
2002-06-18 9:56 ` Kai Großjohann
2002-06-18 11:24 ` Kim F. Storm
2002-06-18 11:29 ` Kai Großjohann
2002-06-18 5:05 ` Eli Zaretskii
2002-06-18 9:56 ` Kai Großjohann
2002-06-19 2:23 ` Richard Stallman
2002-06-19 2:46 ` Miles Bader
2002-06-19 12:40 ` Kim F. Storm
2002-06-21 9:40 ` Richard Stallman
2002-06-21 12:29 ` Kai Großjohann
2002-06-21 15:22 ` Robert J. Chassell
2002-06-21 16:09 ` Kai Großjohann
2002-06-21 20:21 ` Robert J. Chassell
2002-06-21 21:18 ` Kai Großjohann
2002-06-22 22:51 ` Richard Stallman
2002-06-23 16:07 ` Kai Großjohann
2002-06-22 22:51 ` Richard Stallman
2002-06-22 6:59 ` Richard Stallman
2002-06-22 10:14 ` Kai Großjohann
2002-06-22 17:46 ` Stefan Monnier
2002-06-20 14:34 ` Richard Stallman
2002-06-20 15:51 ` Kai Großjohann
2002-06-20 19:48 ` Miles Bader
2002-06-21 16:29 ` Richard Stallman
2002-06-21 19:34 ` Andreas Schwab
2002-06-21 20:52 ` Kai Großjohann
2002-06-22 17:25 ` Stefan Monnier
2002-06-22 22:51 ` Richard Stallman
2002-06-20 16:11 ` Kai Großjohann
2002-06-20 16:31 ` Stefan Monnier
2002-06-20 16:40 ` Robert J. Chassell
2002-06-20 23:02 ` Kim F. Storm
2002-06-20 22:08 ` Miles Bader
2002-06-20 22:20 ` Robert J. Chassell
2002-06-21 7:31 ` Kai Großjohann
2002-06-21 7:45 ` Miles Bader
2002-06-21 12:36 ` Kai Großjohann
2002-06-21 12:38 ` Kai Großjohann
2002-06-21 13:23 ` Miles Bader
2002-06-20 16:41 ` Kai Großjohann
2002-06-21 13:53 ` Robert J. Chassell
2002-06-21 14:23 ` Kai Großjohann
2002-06-21 14:55 ` Robert J. Chassell
2002-06-21 15:50 ` Kai Großjohann
2002-06-21 20:30 ` Robert J. Chassell
2002-06-19 8:42 ` Ehud Karni
2002-06-19 12:45 ` Kim F. Storm
2002-06-19 15:00 ` Stefan Monnier
2002-06-19 21:34 ` Kim F. Storm
2002-06-19 22:35 ` Stefan Monnier
2002-06-21 9:41 ` Richard Stallman
2002-06-20 8:29 ` Kai Großjohann
2002-06-21 9:42 ` Richard Stallman
2002-06-21 9:49 ` Miles Bader
2002-06-21 13:33 ` Jon Cast
2002-06-21 14:25 ` Miles Bader
2002-06-21 14:37 ` Miles Bader
2002-06-22 6:59 ` Richard Stallman
2002-06-22 7:21 ` Michael Kifer
2002-06-22 7:25 ` Miles Bader
2002-06-22 9:41 ` Kai Großjohann
2002-06-22 12:43 ` Miles Bader
2002-06-21 19:30 ` Stefan Monnier
2002-06-19 15:20 ` Robert J. Chassell
2002-06-21 9:40 ` Richard Stallman
2002-06-21 9:48 ` Andreas Schwab
2002-06-21 12:12 ` Kai Großjohann
2002-06-21 14:23 ` Mario Lang
-- strict thread matches above, loose matches on Subject: below --
2002-06-20 14:35 [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye] Richard Stallman
2002-06-20 15:55 ` Robert J. Chassell
2002-06-20 23:27 ` Kim F. Storm
2002-06-21 20:37 ` Robert J. Chassell
2002-06-22 17:20 ` Stefan Monnier
2002-06-22 19:30 ` Alex Schroeder
2002-06-22 20:12 ` Stefan Monnier
2002-06-23 4:57 ` Eli Zaretskii
2002-06-24 9:33 ` Richard Stallman
2002-06-23 18:12 ` Richard Stallman
2002-06-24 7:41 ` Alex Schroeder
2002-06-24 19:40 ` Richard Stallman
2002-06-24 21:17 ` Alex Schroeder
2002-06-24 21:36 ` Miles Bader
2002-06-24 22:01 ` Alex Schroeder
2002-06-24 22:59 ` Miles Bader
2002-06-25 13:54 ` Francesco Potorti`
2002-06-25 14:07 ` Werner LEMBERG
2002-06-26 22:24 ` Richard Stallman
2002-06-27 2:33 ` Miles Bader
2002-06-28 14:33 ` Alex Schroeder
2002-06-29 22:21 ` Richard Stallman
2002-06-28 17:41 ` Richard Stallman
2002-06-30 6:33 ` Eli Zaretskii
2002-06-27 6:49 ` Juanma Barranquero
2002-06-27 8:07 ` Francesco Potorti`
2002-06-28 17:38 ` Richard Stallman
2002-06-24 23:49 ` Jon Cast
2002-06-25 0:16 ` Miles Bader
2002-06-25 1:49 ` Jon Cast
2002-06-25 2:11 ` Miles Bader
2002-06-24 22:47 ` Paul Stoeber
2002-06-23 18:12 ` Richard Stallman
2002-06-21 16:29 ` Richard Stallman
2002-06-29 20:28 No calc in pretest? Kevin A. Burton
2002-06-30 6:24 ` Eli Zaretskii
2002-06-30 6:44 ` Jon Cast
2002-06-30 9:23 ` Eli Zaretskii
2002-06-30 19:06 ` Simon Josefsson
2002-07-02 20:22 ` Jon Cast
2002-07-03 4:57 ` Eli Zaretskii
2002-07-03 21:00 ` Jon Cast
2002-07-04 4:36 ` Eli Zaretskii
2002-07-04 16:37 ` Jon Cast
2002-07-05 17:20 ` Eli Zaretskii
2002-07-05 23:02 ` Jon Cast
2002-07-01 1:55 ` Miles Bader
2002-07-01 5:13 ` Eli Zaretskii
2002-07-02 15:09 ` Stefan Monnier
2002-07-02 15:20 ` Miles Bader
2002-07-02 19:41 ` Jon Cast
2002-07-02 19:54 ` Stefan Monnier
2002-07-02 20:51 ` Jon Cast
2002-07-01 21:32 ` Francesco Potorti`
2002-07-02 8:49 ` Kim F. Storm
2002-07-02 8:06 ` Miles Bader
2002-07-02 9:30 ` Kai Großjohann
2002-07-02 9:43 ` Kim F. Storm
2002-07-02 9:50 ` Juanma Barranquero
2002-07-02 20:44 ` Jon Cast
2002-07-03 2:44 ` Juanma Barranquero
2002-07-03 0:52 ` Jon Cast
2002-07-03 7:58 ` Juanma Barranquero
2002-07-02 10:11 ` Eli Zaretskii
2002-07-02 20:38 ` Jon Cast
2002-07-02 21:46 ` Jason Rumney
2002-07-04 6:08 ` Juanma Barranquero
2002-07-03 20:57 ` Richard Stallman
2002-07-03 21:35 ` Jon Cast
2002-07-03 22:03 ` Miles Bader
2002-07-03 23:08 ` Jon Cast
2002-07-04 18:24 ` Richard Stallman
2002-07-04 23:16 ` Jon Cast
2002-07-05 22:07 ` Richard Stallman
2002-07-05 23:09 ` Jon Cast
2002-07-05 1:20 ` Miles Bader
2002-07-05 22:07 ` Richard Stallman
2002-07-05 23:14 ` Jon Cast
2002-07-05 23:23 ` Francesco Potorti`
2002-07-06 23:31 ` Richard Stallman
2002-07-09 3:22 ` Jon Cast
2002-07-09 18:51 ` Richard Stallman
2002-07-04 22:04 ` Kim F. Storm
2002-07-04 23:31 ` Jon Cast
2002-07-05 20:55 ` Kim F. Storm
2002-07-05 23:07 ` Jon Cast
2002-07-05 22:07 ` Richard Stallman
2002-07-05 23:11 ` Jon Cast
2002-07-05 12:07 ` Kai Großjohann
2002-07-05 13:13 ` Miles Bader
2002-07-05 13:41 ` Kai Großjohann
2002-07-05 22:07 ` Richard Stallman
2002-07-09 2:19 ` Jon Cast
2002-07-09 5:43 ` Eli Zaretskii
2002-07-09 18:51 ` Richard Stallman
2002-07-10 18:24 ` Jon Cast
2002-07-02 10:10 ` Eli Zaretskii
2002-07-02 10:08 ` Eli Zaretskii
2002-07-02 15:28 ` Stefan Monnier
2002-07-02 15:58 ` Miles Bader
2002-07-02 16:05 ` Stefan Monnier
2002-07-02 16:23 ` Miles Bader
2002-07-02 16:26 ` Stefan Monnier
2002-07-02 16:33 ` Miles Bader
2002-07-02 16:38 ` Stefan Monnier
2002-07-02 20:12 ` Jon Cast
2002-07-02 20:09 ` Jon Cast
2002-07-02 20:18 ` Stefan Monnier
2002-07-02 21:15 ` Jon Cast
2002-07-02 19:56 ` Jon Cast
2002-07-02 16:09 ` Simon Josefsson
2002-07-02 16:40 ` Eli Zaretskii
2002-07-02 19:17 ` Stefan Monnier
2002-07-02 20:55 ` Kim F. Storm
2002-07-02 21:04 ` Jon Cast
2002-07-03 4:49 ` Eli Zaretskii
2002-07-02 21:10 ` Kim F. Storm
2002-07-05 17:51 ` Simon Josefsson
2002-07-05 19:14 ` Eli Zaretskii
2002-07-02 20:05 ` Jon Cast
2002-07-02 19:52 ` Jon Cast
2002-07-02 20:05 ` Stefan Monnier
2002-07-02 21:03 ` Jon Cast
2002-07-03 4:05 ` Ken Raeburn
2002-07-03 20:54 ` Jon Cast
2002-07-04 1:35 ` Miles Bader
2002-07-04 1:39 ` Jon Cast
2002-07-03 9:17 ` Kai Großjohann
2002-07-03 21:06 ` Jon Cast
2002-07-02 21:30 ` Robert J. Chassell
2002-07-03 0:33 ` Jon Cast
2002-07-03 20:57 ` Richard Stallman
2002-07-02 20:30 ` Jon Cast
2002-07-02 21:42 ` Kim F. Storm
2002-07-02 21:22 ` Jon Cast
2002-07-02 22:48 ` Kim F. Storm
2002-07-03 0:45 ` Jon Cast
2002-07-03 12:56 ` Kim F. Storm
2002-07-03 21:27 ` Jon Cast
[not found] <sds@gnu.org>
2002-08-06 13:15 ` crash in display, triggered by calendar Sam Steingold
2002-08-06 13:38 ` Ed Reingold
2002-08-06 14:05 ` Sam Steingold
2002-08-06 14:38 ` Alan Shutko
2002-08-06 14:51 ` Ed Reingold
2002-08-06 15:00 ` Sam Steingold
2002-08-07 14:23 ` Richard Stallman
2002-08-07 14:23 ` Richard Stallman
2004-01-16 18:56 ` invalid-regexp in calendar Sam Steingold
2004-01-17 13:49 ` Thien-Thi Nguyen
2004-02-05 2:52 ` Ed Reingold
2004-02-05 20:11 ` D. Goel
2002-08-20 15:32 Suggestions for mode-line-format changes Kim F. Storm
2002-08-20 14:51 ` Romain FRANCOISE
2002-08-21 0:11 ` Richard Stallman
2002-08-21 13:11 ` Kim F. Storm
2002-08-22 3:44 ` Richard Stallman
2002-08-21 0:25 ` Kim F. Storm
2002-08-21 4:29 ` Kenichi Handa
2002-08-21 4:52 ` Miles Bader
2002-08-21 9:33 ` Kim F. Storm
2002-08-21 11:01 ` Miles Bader
2002-08-21 11:09 ` Kenichi Handa
[not found] ` <m2vg63ekjg.fsf@primate.xs4all.nl>
2002-08-22 2:38 ` Miles Bader
2002-08-23 0:11 ` ediff user interface (Re: Suggestions for mode-line-format changes) Karl Eichwalder
2002-08-23 8:28 ` Andreas Schwab
2002-08-24 2:33 ` Suggestions for mode-line-format changes Richard Stallman
2002-08-25 23:36 ` Kim F. Storm
2002-08-25 22:52 ` Miles Bader
2002-08-26 21:16 ` Michael Kifer
2002-08-27 1:52 ` Miles Bader
2002-08-27 2:28 ` Michael Kifer
2002-08-27 2:53 ` Miles Bader
2002-08-27 3:38 ` Michael Kifer
2002-08-27 4:10 ` Miles Bader
2002-08-27 4:33 ` Michael Kifer
2002-08-27 4:56 ` Miles Bader
2002-08-27 5:18 ` Michael Kifer
2002-08-27 5:37 ` Miles Bader
2002-08-27 5:51 ` Michael Kifer
2002-08-27 6:25 ` Miles Bader
2002-08-27 9:16 ` Kim F. Storm
2002-08-27 9:16 ` Kim F. Storm
2002-08-23 16:38 ` Alan Shutko
[not found] ` <m2hehasikt.fsf@primate.xs4all.nl>
2002-09-01 0:07 ` Alan Shutko
2002-09-01 0:32 ` Glenn Morris
2002-08-21 9:29 ` Kim F. Storm
2002-08-23 16:35 ` Alan Shutko
2002-08-24 0:42 ` Kenichi Handa
2002-08-25 18:23 ` Stefan Monnier
2002-08-26 7:01 ` Kenichi Handa
2002-08-26 16:05 ` Stefan Monnier
2002-08-23 16:33 ` Alan Shutko
2002-08-23 16:58 ` Bill White
2002-08-25 23:41 ` Kim F. Storm
2002-08-25 23:12 ` Alan Shutko
2002-08-26 4:42 ` Eli Zaretskii
2002-08-26 7:12 ` Miles Bader
[not found] ` <m265xqsfse.fsf@primate.xs4all.nl>
2002-09-02 1:10 ` Miles Bader
2002-09-02 2:38 ` Alan Shutko
2002-09-02 10:18 ` Kim F. Storm
2002-08-26 10:20 ` Kim F. Storm
2002-08-26 15:51 ` Alan Shutko
2002-08-26 21:51 ` Richard Stallman
2002-08-27 9:20 ` Kim F. Storm
2002-08-27 8:26 ` Miles Bader
2002-08-27 10:34 ` Kim F. Storm
2002-08-28 6:52 ` Richard Stallman
2002-08-26 10:25 ` Mario Lang
2002-08-26 15:01 ` Kim F. Storm
2002-08-26 21:51 ` Richard Stallman
2002-08-23 17:08 ` Kai Großjohann
2002-08-25 5:26 ` Richard Stallman
2002-08-25 5:26 ` Richard Stallman
2002-10-21 7:26 mh-e 6.2 imminent Bill Wohler
2002-10-21 10:04 ` Kim F. Storm
2002-10-21 9:37 ` Juanma Barranquero
2002-10-22 3:13 ` Richard Stallman
2002-10-23 19:48 ` Bill Wohler
2002-10-24 7:25 ` Stefan Monnier
2002-10-24 8:21 ` Miles Bader
[not found] ` <miles@lsi.nec.co.jp>
2002-10-24 9:13 ` Mark D. Baushke
2002-10-24 9:24 ` Miles Bader
2002-10-24 9:28 ` checkdoc (was: mh-e 6.2 imminent) Stefan Monnier
2002-10-24 11:13 ` Kim F. Storm
2002-10-24 14:45 ` Miles Bader
2002-10-24 16:15 ` Kim F. Storm
2002-10-24 23:30 ` Miles Bader
2002-10-25 5:35 ` Richard Stallman
2002-10-25 9:23 ` Kim F. Storm
2002-10-26 20:15 ` Richard Stallman
2002-10-26 23:03 ` Kim F. Storm
2002-10-28 19:19 ` Richard Stallman
2002-10-28 19:38 ` Henrik Enberg
2002-10-28 21:37 ` Miles Bader
2002-10-28 23:19 ` Kim F. Storm
2002-10-28 23:22 ` Miles Bader
2002-10-29 0:46 ` Kim F. Storm
2002-10-29 11:07 ` Henrik Enberg
2002-10-29 14:31 ` Stefan Monnier
2002-10-28 21:53 ` Kim F. Storm
2002-10-29 1:20 ` Miles Bader
2002-10-29 11:29 ` Richard Stallman
2002-10-29 11:28 ` Richard Stallman
2002-10-29 12:55 ` Miles Bader
2002-11-02 0:58 ` Henrik Enberg
2002-11-05 4:26 ` Miles Bader
2002-10-25 5:35 ` mh-e 6.2 imminent Richard Stallman
2002-10-25 5:50 ` Miles Bader
2002-10-26 20:15 ` Richard Stallman
2002-10-29 17:30 ` Francesco Potorti`
2002-10-30 2:22 ` Miles Bader
[not found] ` <pot@gnu.org>
2002-10-29 17:38 ` Peter S Galbraith
2002-10-30 17:18 ` Richard Stallman
2002-11-02 12:07 ` Francesco Potorti`
2003-01-07 12:40 ` etags -f /dev/stdout enhancement request Francesco Potorti`
2003-01-07 17:16 ` Lyndon Nerenberg
[not found] <E18UXkO-00014i-00@troodon.localdomain>
2003-01-04 23:44 ` Emacs crash in X Richard Stallman
2003-05-25 23:01 S-backspace Alex Schroeder
2003-05-25 23:57 ` S-backspace Miles Bader
2003-05-26 1:14 ` S-backspace Luc Teirlinck
[not found] ` <200305260121.h4Q1L0s14572@eel.dms.auburn.edu>
2003-05-26 1:24 ` S-backspace Luc Teirlinck
2003-05-26 1:38 ` S-backspace Luc Teirlinck
2003-05-26 14:24 ` S-backspace Oliver Scholz
2003-05-26 18:59 ` S-backspace Luc Teirlinck
2003-05-26 15:18 ` S-backspace Kai Großjohann
2003-05-27 12:44 ` S-backspace Richard Stallman
2003-05-27 13:57 ` S-backspace Kai Großjohann
2003-05-27 14:06 ` S-backspace Rajesh Vaidheeswarran
2003-05-27 14:16 ` S-backspace David Kastrup
2003-05-27 14:18 ` S-backspace Miles Bader
2003-05-27 15:46 ` S-backspace Kai Großjohann
2003-05-27 16:47 ` S-backspace Luc Teirlinck
2003-05-27 17:06 ` S-backspace Stefan Monnier
2003-05-27 17:04 ` S-backspace Luc Teirlinck
2003-05-27 16:26 ` S-backspace Luc Teirlinck
2003-05-28 23:57 ` S-backspace Richard Stallman
2003-05-29 0:25 ` S-backspace Stefan Monnier
2003-05-29 2:33 ` S-backspace Peter Lee
2003-05-29 7:54 ` S-backspace Oliver Scholz
2003-05-30 1:10 ` S-backspace Luc Teirlinck
2003-06-05 1:49 ` S-backspace Luc Teirlinck
2003-06-05 2:40 ` S-backspace Miles Bader
2003-06-05 3:12 ` { SPAM 2 }::Re: S-backspace Luc Teirlinck
2003-05-31 19:44 ` S-backspace David Kastrup
2003-05-29 1:46 ` S-backspace Luc Teirlinck
2003-05-29 2:11 ` S-backspace Luc Teirlinck
2003-05-30 17:12 ` S-backspace Richard Stallman
2003-05-30 22:22 ` S-backspace Kevin Rodgers
2003-05-30 23:59 ` S-backspace Kim F. Storm
2003-06-04 11:13 ` S-backspace Andreas Schwab
2003-05-31 0:39 ` S-backspace Luc Teirlinck
2003-05-31 0:53 ` S-backspace Miles Bader
2003-05-31 0:58 ` S-backspace Luc Teirlinck
2003-05-31 1:07 ` S-backspace Miles Bader
2003-05-27 14:31 ` S-backspace Jan D.
2003-05-28 13:54 ` S-backspace Richard Stallman
2003-10-12 19:47 RMAIL, MIME-related bug Alexander Pohoyda
2003-10-14 1:50 ` Kenichi Handa
2003-10-14 14:05 ` Robert J. Chassell
[not found] ` <bob@rattlesnake.com>
2003-04-11 17:21 ` `whitespace-describe' function missing Robert J. Chassell
2003-04-14 2:01 ` Rajesh Vaidheeswarran
2003-04-14 11:55 ` Robert J. Chassell
2003-04-14 15:23 ` Kim F. Storm
2003-05-13 14:38 ` Rajesh Vaidheeswarran
2003-05-13 15:30 ` Stefan Monnier
2003-10-15 19:59 ` RMAIL, MIME-related bug Peter S Galbraith
2005-05-04 19:59 ` bootstrap from scratch Robert J. Chassell
2005-05-05 0:24 ` Ed Reingold
2005-05-05 11:21 ` Robert J. Chassell
2005-05-05 17:18 ` Ed Reingold
2005-05-05 18:42 ` Alan Shutko
2005-05-05 19:10 ` Ed Reingold
2005-05-05 19:24 ` Alan Shutko
2005-05-05 19:30 ` Ed Reingold
2005-05-05 19:37 ` Glenn Morris
2005-05-05 19:42 ` org.el fix Alan Shutko
2005-05-05 19:54 ` bootstrap from scratch Stefan Monnier
2005-05-05 20:10 ` Glenn Morris
2005-05-05 22:29 ` Kim F. Storm
2005-05-05 23:28 ` Jason Rumney
2005-05-06 10:30 ` bootstrap from scratch [is now appt activation] Marcelo Toledo
2005-05-06 22:23 ` Jason Rumney
2005-05-06 18:51 ` bootstrap from scratch Richard Stallman
2005-05-06 22:26 ` Jason Rumney
2005-05-07 18:35 ` Richard Stallman
2005-05-06 18:50 ` Richard Stallman
2005-05-06 20:38 ` Glenn Morris
2005-05-05 20:02 ` Glenn Morris
2005-05-06 18:50 ` Richard Stallman
2005-05-06 18:51 ` Richard Stallman
2005-05-05 1:32 ` Marcelo Toledo
2005-05-05 19:33 ` Glenn Morris
2003-10-15 4:08 ` RMAIL, MIME-related bug Richard Stallman
2003-10-16 6:59 ` Eli Zaretskii
2003-10-16 7:41 ` Alexander Pohoyda
2003-10-16 9:40 ` Thien-Thi Nguyen
2003-10-16 9:48 ` Thien-Thi Nguyen
2003-10-16 13:27 ` Alexander Pohoyda
2003-10-16 14:15 ` Thien-Thi Nguyen
2003-10-16 11:20 ` Eli Zaretskii
2003-10-16 13:14 ` Alexander Pohoyda
2003-10-16 16:02 ` Eli Zaretskii
2003-10-16 18:27 ` David Kastrup
2003-10-16 21:18 ` Alexander Pohoyda
2003-10-17 7:00 ` Eli Zaretskii
2003-10-16 14:36 ` Ehud Karni
2003-10-16 16:06 ` Eli Zaretskii
2003-10-16 23:06 ` Richard Stallman
2003-10-16 23:06 ` Richard Stallman
2003-10-17 6:19 ` Alexander Pohoyda
2003-10-17 6:45 ` Eli Zaretskii
2003-10-16 16:54 ` Stefan Monnier
2003-10-16 17:21 ` Eli Zaretskii
2003-10-16 18:49 ` Stefan Monnier
2003-10-16 18:58 ` Eli Zaretskii
2003-10-16 19:21 ` Stefan Monnier
2003-10-17 6:24 ` Eli Zaretskii
2003-10-17 11:54 ` Stephen J. Turnbull
2003-10-17 18:10 ` Eli Zaretskii
2003-10-21 3:09 ` Stephen J. Turnbull
2003-10-21 3:59 ` Simon Josefsson
2003-10-21 10:50 ` Stephen J. Turnbull
2003-10-21 11:56 ` Lars Magne Ingebrigtsen
2003-10-22 9:25 ` Richard Stallman
2003-10-22 10:52 ` Stephen J. Turnbull
2003-10-22 10:52 ` Kenichi Handa
2003-10-29 11:30 ` 守岡知彦 / MORIOKA Tomohiko
2003-10-22 17:19 ` Alexander Pohoyda
2003-10-22 19:53 ` Lars Magne Ingebrigtsen
2003-10-22 23:47 ` Kenichi Handa
2003-10-17 18:51 ` Satyaki Das
2003-10-17 18:57 ` Lars Magne Ingebrigtsen
2003-10-18 8:29 ` Eli Zaretskii
2003-10-18 23:05 ` Richard Stallman
2003-10-19 5:50 ` Eli Zaretskii
2003-10-19 10:38 ` Alex Schroeder
2003-10-20 1:48 ` Richard Stallman
2003-10-20 5:53 ` Alexander Pohoyda
2003-10-20 6:51 ` Lars Magne Ingebrigtsen
2003-10-20 17:39 ` Alexander Pohoyda
2003-10-20 23:20 ` Richard Stallman
2003-12-26 17:40 ` Merging quoted-printable functions Alexander Pohoyda
2003-12-27 22:16 ` Richard Stallman
2003-10-16 19:33 ` RMAIL, MIME-related bug Ehud Karni
2003-10-17 6:20 ` Eli Zaretskii
2003-10-16 19:14 ` Ehud Karni
2003-10-16 21:56 ` Alexander Pohoyda
2003-10-16 22:21 ` Ehud Karni
2003-10-16 23:48 ` Luc Teirlinck
2003-10-17 2:20 ` Kenichi Handa
[not found] ` <eliz@elta.co.il>
2003-10-17 2:36 ` Peter S Galbraith
2003-10-17 15:39 ` Peter S Galbraith
2003-10-17 16:16 ` Stefan Monnier
[not found] ` <monnier@IRO.UMontreal.CA>
2003-10-17 16:22 ` Peter S Galbraith
2003-10-17 18:17 ` Eli Zaretskii
2003-10-17 18:33 ` Peter S Galbraith
2003-10-20 10:43 ` Richard Stallman
2003-10-17 20:46 ` Richard Stallman
2003-10-17 21:09 ` Stefan Monnier
2003-10-18 23:06 ` Richard Stallman
2003-10-19 7:46 ` Alexander Pohoyda
2003-10-22 20:26 ` RMAIL, rmail-mbox-branch Alexander Pohoyda
2003-10-27 23:44 ` Richard Stallman
2003-11-26 22:44 ` Alexander Pohoyda
2003-10-16 21:44 ` RMAIL, MIME-related bug Alexander Pohoyda
2003-10-16 22:07 ` Stefan Monnier
2003-10-16 21:44 ` Alexander Pohoyda
2003-10-19 20:59 ` Juri Linkov
2003-10-20 4:18 ` Kenichi Handa
2003-10-20 5:15 ` Juri Linkov
2003-10-20 5:21 ` Alexander Pohoyda
2003-10-20 13:03 ` Robert J. Chassell
2003-10-20 6:54 ` Lars Magne Ingebrigtsen
2003-10-20 8:11 ` Juri Linkov
2003-10-20 9:33 ` Lars Magne Ingebrigtsen
2003-10-20 13:56 ` Paul Michael Reilly
2003-10-20 17:14 ` Satyaki Das
2003-10-21 14:48 ` Richard Stallman
2003-10-21 16:48 ` Satyaki Das
2003-10-20 23:20 ` Richard Stallman
2003-10-21 5:30 ` Karl Eichwalder
2003-10-22 9:25 ` Richard Stallman
2003-10-20 23:38 ` Kevin Rodgers
2003-10-21 5:38 ` Juri Linkov
2003-10-21 14:40 ` URL (was: RMAIL, MIME-related bug) Stefan Monnier
2003-10-23 15:48 ` URL Dave Love
2003-10-23 16:31 ` URL Stefan Monnier
2003-10-24 5:16 ` URL Richard Stallman
2003-10-25 16:20 ` URL Dave Love
2003-10-27 13:16 ` URL Juri Linkov
2003-10-23 18:24 ` RMAIL, MIME-related bug Kevin Rodgers
2003-10-23 19:57 ` Kevin Rodgers
2003-10-27 13:03 ` URL Juri Linkov
2003-10-19 1:34 customizing a variable named in Info Peter S Galbraith
2003-10-19 5:58 ` Eli Zaretskii
2003-10-19 15:12 ` Luc Teirlinck
[not found] ` <teirllm@dms.auburn.edu>
2003-10-19 17:17 ` Peter S Galbraith
2003-10-20 1:48 ` Richard Stallman
2003-11-14 20:22 doc elisp intro cross reference fixes Kevin Ryde
2003-11-17 13:29 ` Juri Linkov
2003-11-17 20:12 ` Robert J. Chassell
2003-11-18 15:34 ` Juri Linkov
2003-11-19 21:06 ` Robert J. Chassell
2003-11-18 23:04 ` Richard Stallman
2003-11-19 3:08 ` Stefan Monnier
2003-11-19 4:18 ` Luc Teirlinck
2003-11-19 4:29 ` Stefan Monnier
2003-11-19 5:05 ` Luc Teirlinck
2003-11-19 13:53 ` Stefan Monnier
2003-11-19 5:28 ` Luc Teirlinck
2003-11-19 13:56 ` Stefan Monnier
2003-11-19 20:23 ` Kevin Rodgers
2003-11-19 21:15 ` Stefan Monnier
2003-11-19 22:38 ` Luc Teirlinck
2003-11-20 4:53 ` Stefan Monnier
2003-11-20 13:13 ` David Kastrup
2003-11-20 14:35 ` Stefan Monnier
2003-11-20 14:47 ` David Kastrup
2003-11-20 15:43 ` Stefan Monnier
2003-11-20 20:21 ` Kevin Rodgers
2003-11-20 14:51 ` David Kastrup
2003-11-20 15:46 ` Stefan Monnier
2003-11-20 20:33 ` Kevin Rodgers
2003-11-20 20:58 ` David Kastrup
2003-11-26 18:09 ` Per Abrahamsen
2003-11-26 18:14 ` Stefan Monnier
2003-11-26 23:49 ` Luc Teirlinck
2003-11-27 0:51 ` Stefan Monnier
2003-11-27 3:22 ` Luc Teirlinck
2003-11-27 3:45 ` Luc Teirlinck
2003-11-28 23:14 ` Richard Stallman
2003-11-29 20:29 ` Luc Teirlinck
2003-11-28 23:15 ` Richard Stallman
2003-11-26 23:58 ` Luc Teirlinck
2003-11-27 0:14 ` Luc Teirlinck
2003-11-27 11:26 ` Per Abrahamsen
2003-11-27 16:11 ` Luc Teirlinck
2003-11-27 16:48 ` Luc Teirlinck
2003-11-27 18:46 ` Per Abrahamsen
[not found] ` <200311271857.hARIvGr04327@raven.dms.auburn.edu>
2003-11-27 19:09 ` Per Abrahamsen
[not found] ` <200311271946.hARJkhd04426@raven.dms.auburn.edu>
[not found] ` <jwvy8u1bmfq.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>
[not found] ` <200311272115.hARLFFo04571@raven.dms.auburn.edu>
2003-11-28 11:41 ` Per Abrahamsen
[not found] ` <200311281810.hASIACS06152@raven.dms.auburn.edu>
[not found] ` <x5znegpcue.fsf@lola.goethe.zz>
[not found] ` <200311281853.hASIrSg06209@raven.dms.auburn.edu>
[not found] ` <x5fzg8p873.fsf@lola.goethe.zz>
2003-11-29 15:40 ` Per Abrahamsen
2003-11-28 23:14 ` Richard Stallman
2003-11-29 14:04 ` Per Abrahamsen
[not found] ` <200311291445.hATEjN408572@raven.dms.auburn.edu>
2003-11-29 16:54 ` Per Abrahamsen
[not found] ` <200311291828.hATISht08904@raven.dms.auburn.edu>
2003-11-30 13:06 ` Per Abrahamsen
2003-11-30 15:19 ` Luc Teirlinck
[not found] ` <E1AQd7O-0002KQ-Bb@fencepost.gnu.org>
2003-12-01 11:06 ` Per Abrahamsen
2003-12-02 4:17 ` Richard Stallman
2003-11-27 11:03 ` Per Abrahamsen
2003-11-27 19:08 ` Richard Stallman
2003-11-28 10:45 ` Per Abrahamsen
2003-11-19 23:48 ` Luc Teirlinck
2003-11-19 23:56 ` Miles Bader
2003-11-20 20:18 ` Kevin Rodgers
2003-11-20 4:58 ` Stefan Monnier
2003-11-20 5:12 ` Luc Teirlinck
2003-11-20 14:39 ` Stefan Monnier
2003-11-20 20:13 ` Kevin Rodgers
2003-11-20 22:35 ` Stefan Monnier
2003-11-29 21:25 ` Kai Grossjohann
2003-11-30 19:51 ` Stefan Monnier
2003-11-30 20:31 ` Kai Grossjohann
2003-11-30 21:08 ` Stefan Monnier
2003-12-01 21:14 ` Kai Grossjohann
2003-12-02 16:17 ` Stefan Monnier
2003-12-03 4:45 ` Richard Stallman
2003-12-01 1:45 ` Richard Stallman
2003-11-21 4:08 ` Richard Stallman
2003-11-21 4:28 ` Miles Bader
2003-11-21 15:03 ` Stefan Monnier
2003-11-23 16:34 ` Richard Stallman
2003-11-20 4:06 ` Richard Stallman
2003-11-20 4:57 ` Stefan Monnier
2003-11-20 20:20 ` Kevin Rodgers
2003-11-20 22:36 ` Stefan Monnier
2003-11-26 18:03 ` Per Abrahamsen
2003-11-26 18:55 ` Simon Josefsson
2003-11-27 7:28 ` Juri Linkov
2003-11-27 11:10 ` Per Abrahamsen
2003-11-28 23:14 ` Richard Stallman
[not found] ` <juri@jurta.org>
2003-11-28 1:47 ` Peter S Galbraith
2003-11-18 20:48 ` Kevin Ryde
2003-11-18 21:31 ` Juri Linkov
2003-11-20 21:42 ` Kevin Ryde
2004-05-04 18:28 dired alignment Karl Eichwalder
2004-05-04 21:32 ` Andreas Schwab
2004-05-05 20:20 ` Richard Stallman
2004-05-05 21:12 ` Stefan Monnier
2004-05-07 0:28 ` Richard Stallman
2004-05-07 14:55 ` Peter Whaite
2004-05-08 21:59 ` Richard Stallman
2004-05-12 15:49 ` Peter Whaite
2004-05-12 17:01 ` Stefan Monnier
2004-05-13 15:46 ` Richard Stallman
2004-05-13 16:43 ` Andreas Schwab
2004-05-14 21:01 ` Richard Stallman
2004-05-14 22:16 ` Andreas Schwab
2004-05-13 19:34 ` Miles Bader
2004-05-14 21:02 ` Richard Stallman
2004-05-14 23:32 ` Miles Bader
2004-05-07 16:32 ` Edward O'Connor
2004-05-04 22:27 Fix for inconsistent (/ DIVIDEND DIVISOR &rest DIVISORS) Peter Whaite
2004-05-04 22:51 ` Miles Bader
2004-05-04 23:21 ` Peter Whaite
2004-05-04 23:50 ` David Kastrup
2004-05-05 7:16 Mode-line customization Matt Hodges
2004-05-05 15:04 ` Chris Green
2004-05-05 21:19 ` Juanma Barranquero
2004-05-06 9:22 ` Richard Stallman
2004-05-06 9:40 ` Miles Bader
2004-05-06 10:00 ` David Kastrup
2004-05-06 10:44 ` Miles Bader
2004-05-06 11:59 ` Kim F. Storm
2004-05-06 14:06 ` Miles Bader
2004-05-06 14:43 ` David Kastrup
2004-05-07 1:49 ` Miles Bader
2004-05-07 7:47 ` David Kastrup
2004-05-07 17:02 ` Kevin Rodgers
2004-05-07 18:14 ` Stefan Monnier
2004-05-08 21:59 ` Richard Stallman
2004-05-06 15:38 ` David Kastrup
2004-05-08 1:20 ` Richard Stallman
2004-05-06 14:59 ` Stefan Monnier
2004-05-06 17:38 ` Peter Whaite
2004-05-11 12:50 ` Chris Green
2004-05-06 0:17 ` Masatake YAMATO
2004-10-25 12:04 $HOME default on w32 Stefan
2004-10-25 15:06 ` Lennart Borgman
2004-10-25 16:31 ` CHENG Gao
2004-10-25 17:34 ` Stefan Monnier
2004-10-25 18:41 ` Stefan Daschek
2004-10-26 7:32 ` Kai Grossjohann
2004-10-26 16:32 ` Stefan Monnier
2004-10-27 2:40 ` Jay Finger
2004-10-27 3:13 ` Stefan Monnier
2004-10-27 6:19 ` Stephan Stahl
2004-10-27 6:58 ` Cheng Gao
2004-10-27 8:50 ` Lennart Borgman
2004-10-27 12:58 ` Stefan Monnier
2004-10-27 17:14 ` Jay Finger
2004-10-27 17:37 ` Lennart Borgman
2004-10-28 5:24 ` Jay Finger
2004-10-27 17:53 ` Stefan Monnier
2004-10-27 20:49 ` Peter Whaite
2004-10-27 21:31 ` Adrian Aichner
2004-10-28 5:45 ` Jay Finger
2004-10-25 18:04 ` Guy Gascoigne - Piggford
2004-10-25 19:12 ` Jason Rumney
2004-10-25 20:24 ` Lennart Borgman
2005-03-10 21:40 calendar problems Karl Chen
2005-03-10 23:06 ` Alan Shutko
2005-03-11 1:32 ` Ed Reingold
2005-03-11 17:01 ` Alan Shutko
2005-03-12 0:56 ` Richard Stallman
2005-03-13 0:40 ` Ed Reingold
2005-03-14 3:00 ` Richard Stallman
2005-03-19 21:22 RMAIL slows Robert J. Chassell
2005-03-19 22:04 ` David Kastrup
2005-03-20 12:59 ` Richard Stallman
2005-03-21 17:44 ` Robert J. Chassell
2005-03-22 13:56 ` Richard Stallman
2005-03-22 15:42 ` Robert J. Chassell
2005-03-22 18:55 ` Stefan Monnier
2005-03-23 0:59 ` Richard Stallman
2005-03-23 14:50 ` Robert J. Chassell
2005-03-24 5:19 ` Richard Stallman
2005-03-29 12:18 ` Robert J. Chassell
2005-04-08 19:40 ` Robert J. Chassell
2005-04-08 22:57 ` Stefan Monnier
2005-04-08 23:53 ` Kim F. Storm
2005-04-12 17:49 ` Robert J. Chassell
2005-04-12 19:51 ` Stefan Monnier
2005-04-12 21:45 ` David Kastrup
2005-04-13 11:10 ` Robert J. Chassell
2005-04-13 18:31 ` Richard Stallman
2005-04-13 19:54 ` David Kastrup
2005-04-14 19:03 ` Richard Stallman
2005-04-15 0:41 ` Robert J. Chassell
2005-04-16 2:58 ` Richard Stallman
2005-04-20 10:42 ` Robert J. Chassell
2005-04-20 21:42 ` Richard Stallman
2005-04-22 22:46 ` Robert J. Chassell
2005-04-23 22:24 ` Richard Stallman
2005-04-25 10:23 ` Robert J. Chassell
2005-04-26 10:05 ` Richard Stallman
2005-05-04 11:31 ` Robert J. Chassell
2005-05-05 14:13 ` Stefan Monnier
2005-05-05 17:56 ` Robert J. Chassell
2005-05-05 22:45 ` Kevin Rodgers
2005-05-06 15:34 ` Robert J. Chassell
2005-05-06 17:32 ` Stefan Monnier
2005-05-06 18:49 ` Robert J. Chassell
2005-05-06 20:50 ` Stefan Monnier
2005-05-07 11:08 ` Robert J. Chassell
2005-05-10 11:04 ` Robert J. Chassell
2005-05-10 15:56 ` Should overlays evaporate by default? Peter Whaite
2005-05-11 16:27 ` Richard Stallman
2005-05-12 8:18 ` Kim F. Storm
2005-05-13 1:34 ` Richard Stallman
2005-05-13 8:17 ` Kim F. Storm
2005-05-14 0:25 ` Richard Stallman
2005-05-16 14:59 ` Peter Whaite
2005-05-16 21:21 ` Richard Stallman
2005-05-17 16:20 ` Peter Whaite
2005-05-18 5:19 ` Richard Stallman
2005-05-18 0:15 ` Thien-Thi Nguyen
2005-05-18 22:45 ` Richard Stallman
2005-05-19 8:24 ` Thien-Thi Nguyen
2005-05-19 22:39 ` Richard Stallman
2005-05-20 19:15 ` Peter Whaite
2005-05-27 19:23 ` Should overlays evaporate by default? Conclusion: No! Peter Whaite
2005-05-28 11:52 ` Richard Stallman
2005-05-30 16:22 ` Peter Whaite
2005-05-31 10:54 ` Richard Stallman
2005-05-06 19:03 ` RMAIL slows Robert J. Chassell
2005-05-06 18:57 ` Richard Stallman
2005-05-06 19:20 ` Robert J. Chassell
2005-05-05 19:46 ` Richard Stallman
2005-07-05 17:54 SPC in custom-mode Lennart Borgman
2005-07-07 17:05 ` Per Abrahamsen
2005-07-07 17:37 ` Lennart Borgman
2005-07-08 10:17 ` Per Abrahamsen
2005-07-07 20:34 ` Peter Whaite
2005-07-07 21:21 ` Lennart Borgman
2005-07-07 23:18 ` Peter Whaite
2005-07-07 23:27 ` Lennart Borgman
2005-07-08 6:52 ` Mathias Dahl
2005-07-08 7:24 ` Joakim Verona
2005-07-08 4:36 ` Richard M. Stallman
2005-12-02 2:13 fancy-splash-screen customize group David Kastrup
2005-12-03 1:19 ` Richard M. Stallman
2005-12-03 8:20 ` David Kastrup
2005-12-04 3:08 ` Richard M. Stallman
2005-12-04 11:54 ` David Kastrup
2005-12-04 15:17 ` Stefan Monnier
2005-12-03 11:26 ` Romain Francoise
2005-12-03 18:03 ` David Kastrup
2005-12-04 18:51 ` Chong Yidong
2005-12-04 18:54 ` Chong Yidong
2005-12-04 21:38 ` Drew Adams
2005-12-05 16:38 ` Richard M. Stallman
2005-12-05 17:52 ` Chong Yidong
2005-12-05 18:47 ` Peter Whaite
2005-12-06 0:02 ` Xavier Maillard
2005-12-06 16:42 ` Richard M. Stallman
2005-12-06 17:17 ` Chong Yidong
2005-12-06 19:09 ` Peter Whaite
2005-12-06 20:31 ` Lennart Borgman
2005-12-06 21:19 ` Chong Yidong
2005-12-06 23:01 ` Jason Rumney
2005-12-06 23:28 ` Luc Teirlinck
2005-12-06 23:37 ` Lennart Borgman
2005-12-07 0:11 ` Luc Teirlinck
2005-12-07 0:34 ` Lennart Borgman
2005-12-07 17:39 ` Xavier Maillard
2005-12-07 17:37 ` Peter Whaite
2005-12-07 21:28 ` Juri Linkov
2005-12-07 22:38 ` Lennart Borgman
2005-12-07 23:21 ` Peter Whaite
2005-12-07 23:25 ` Lennart Borgman
2005-12-07 23:49 ` Peter Whaite
2005-12-08 0:39 ` Lennart Borgman
2005-12-08 21:54 ` Peter Whaite
2005-12-08 1:00 ` Juri Linkov
2005-12-08 2:30 ` Luc Teirlinck
2005-12-08 21:57 ` Juri Linkov
2005-12-09 0:57 ` Luc Teirlinck
2005-12-09 1:08 ` Lennart Borgman
2005-12-09 1:30 ` Luc Teirlinck
2005-12-09 17:32 ` Peter Whaite
2005-12-10 4:13 ` Richard M. Stallman
2005-12-09 15:04 ` Richard M. Stallman
2005-12-09 1:27 ` unexec and fedora core 4 Camm Maguire
2005-12-09 15:04 ` Richard M. Stallman
[not found] ` <slrndpilut.ha3.jsnell@dogbert.localdomain>
2005-12-09 15:17 ` Camm Maguire
2005-12-09 21:43 ` Camm Maguire
2005-12-10 9:20 ` [Gcl-devel] " Eli Zaretskii
2005-12-13 3:15 ` Camm Maguire
2005-12-08 2:42 ` fancy-splash-screen customize group Luc Teirlinck
2005-12-08 3:21 ` Luc Teirlinck
2005-12-08 8:47 ` Lennart Borgman
2005-12-08 15:38 ` Luc Teirlinck
2005-12-08 16:38 ` Luc Teirlinck
2005-12-07 23:27 ` Luc Teirlinck
2005-12-08 2:59 ` Chong Yidong
[not found] ` <200512072321.jB7NLMR03715@raven.dms.auburn.edu>
2005-12-07 23:32 ` Lennart Borgman
2005-12-07 23:46 ` Luc Teirlinck
2005-12-07 23:38 ` Peter Whaite
2005-12-07 23:52 ` Luc Teirlinck
2005-12-09 17:42 ` Peter Whaite
2005-12-08 19:27 ` Richard M. Stallman
2005-12-08 21:34 ` Peter Whaite
2005-12-09 15:02 ` Richard M. Stallman
2005-12-09 15:02 ` Richard M. Stallman
2005-12-09 17:40 ` Lennart Borgman
2005-12-09 18:34 ` Peter Whaite
2005-12-10 4:14 ` Richard M. Stallman
2005-12-10 14:38 ` Lennart Borgman
2005-12-10 15:21 ` Luc Teirlinck
2005-12-10 19:29 ` Lennart Borgman
2005-12-11 3:40 ` Luc Teirlinck
2005-12-11 18:55 ` Drew Adams
2005-12-12 4:55 ` Luc Teirlinck
2005-12-12 5:24 ` Richard M. Stallman
2005-12-12 5:40 ` Drew Adams
2005-12-13 3:50 ` Luc Teirlinck
2005-12-13 23:33 ` Richard M. Stallman
2005-12-11 22:57 ` Richard M. Stallman
2005-12-11 5:03 ` Richard M. Stallman
2005-12-11 6:23 ` Luc Teirlinck
2005-12-11 22:26 ` Lennart Borgman
2005-12-12 4:48 ` Luc Teirlinck
2005-12-11 22:56 ` Richard M. Stallman
2005-12-11 5:03 ` Richard M. Stallman
2005-12-09 2:25 ` Luc Teirlinck
2005-12-09 17:30 ` Lennart Borgman
2005-12-09 18:06 ` Peter Whaite
2005-12-10 4:13 ` Richard M. Stallman
2005-12-09 21:15 ` Richard M. Stallman
2005-12-09 23:15 ` Luc Teirlinck
2005-12-10 16:18 ` Richard M. Stallman
[not found] ` <87pso8l2l7.fsf@stupidchicken.com>
2005-12-08 19:29 ` Richard M. Stallman
2005-12-11 22:57 ` Richard M. Stallman
2005-12-13 1:27 ` Lennart Borgman
2005-12-13 23:33 ` Richard M. Stallman
2005-12-19 16:04 ` Lennart Borgman
2005-12-20 16:33 ` Richard M. Stallman
2005-12-07 22:46 ` Lennart Borgman
2005-12-07 22:48 ` Peter Whaite
2005-12-07 0:14 ` Luc Teirlinck
2005-12-06 23:18 ` Lennart Borgman
2005-12-07 7:57 ` Help links (was: fancy-splash-screen customize group...) Juri Linkov
2005-12-07 9:05 ` Help links Lennart Borgman
2005-12-07 22:59 ` Richard M. Stallman
2005-12-07 17:07 ` fancy-splash-screen customize group Richard M. Stallman
2005-12-09 17:49 ` Lennart Borgman
2005-12-07 4:25 ` Luc Teirlinck
2005-12-07 16:45 ` Drew Adams
2005-12-07 18:27 ` Lennart Borgman
2005-12-07 18:36 ` Drew Adams
2005-12-07 20:22 ` Lennart Borgman
2005-12-07 20:27 ` Peter Whaite
2005-12-07 17:06 ` Richard M. Stallman
2005-12-07 18:26 ` Peter Whaite
2005-12-11 22:57 ` Richard M. Stallman
2005-12-07 17:06 ` Richard M. Stallman
2005-12-07 18:21 ` Peter Whaite
2005-12-07 17:06 ` Richard M. Stallman
2005-12-07 16:38 ` Drew Adams
2005-12-08 4:55 ` Richard M. Stallman
2005-12-06 16:41 ` Richard M. Stallman
2005-12-04 21:18 ` Richard M. Stallman
2005-12-04 21:22 ` David Kastrup
2005-12-10 4:07 ` Luc Teirlinck
2005-12-10 16:19 ` Richard M. Stallman
[not found] <E1EjJLn-0005bC-6Q@fencepost.gnu.org>
2005-12-07 2:10 ` [evilborisnet@netscape.net: weird behavior of ediff with multiple displays] Michael Kifer
2005-12-07 22:58 ` Richard M. Stallman
2005-12-07 23:53 ` Michael Kifer
2005-12-08 19:27 ` Richard M. Stallman
2005-12-08 20:34 ` Lőrentey Károly
2005-12-09 15:04 ` Richard M. Stallman
2005-12-08 21:27 ` Michael Kifer
2005-12-08 13:24 ` Lőrentey Károly
2005-12-09 8:34 newsticker-start: Recursive laod error Sascha Wilde
2005-12-10 8:55 ` Xavier Maillard
2005-12-10 10:38 ` Lennart Borgman
2005-12-10 14:12 ` Robert J. Chassell
2005-12-11 5:02 ` Richard M. Stallman
2005-12-11 8:51 ` Xavier Maillard
2005-12-11 22:56 ` Richard M. Stallman
2005-12-12 21:00 ` Xavier Maillard
2005-12-14 9:24 ` Sascha Wilde
2005-12-14 15:35 ` Lennart Borgman
2005-12-14 15:43 ` Sascha Wilde
2005-12-15 17:13 ` Xavier Maillard
2005-12-15 17:28 ` Lennart Borgman
2005-12-15 19:47 ` Eli Zaretskii
2005-12-15 15:11 ` Sascha Wilde
2005-12-15 15:53 ` Lennart Borgman
2005-12-16 1:52 ` Richard M. Stallman
2005-12-10 10:44 ` Eli Zaretskii
[not found] ` <eliz@gnu.org>
2005-12-10 14:28 ` Ulf Jasper
2005-12-10 19:32 ` Eli Zaretskii
2005-12-10 19:59 ` Lennart Borgman
2005-12-11 16:49 ` Richard M. Stallman
2005-12-11 0:25 ` Xavier Maillard
2005-12-11 11:40 ` Romain Francoise
[not found] ` <romain@orebokech.com>
2005-12-12 18:39 ` Ulf Jasper
2005-12-12 22:00 ` Thien-Thi Nguyen
2005-12-12 23:36 ` Thien-Thi Nguyen
2005-12-13 15:54 ` Stefan Monnier
2005-12-13 21:08 ` Thien-Thi Nguyen
2005-12-13 21:40 ` Stefan Monnier
[not found] ` <monnier@iro.umontreal.ca>
2005-12-14 19:22 ` Ulf Jasper
2005-12-14 22:16 ` Tomas Zerolo
2005-12-15 0:35 ` Thien-Thi Nguyen
2005-12-15 1:51 ` Drew Adams
[not found] ` <ttn@gnu.org>
2005-12-15 20:18 ` Ulf Jasper
2006-01-24 16:55 Documentation for car and cdr Mario Domenech Goulart
2006-01-24 22:30 ` Kevin Rodgers
2006-01-24 21:45 ` Mario Domenech Goulart
2006-01-24 23:14 ` David Kastrup
2006-01-25 8:37 ` Mario Domenech Goulart
2006-01-25 11:07 ` David Kastrup
2006-01-25 12:42 ` Andreas Schwab
2006-01-25 12:47 ` David Kastrup
2006-01-25 15:44 ` Richard M. Stallman
2006-01-25 19:54 ` Alan Mackenzie
2006-01-25 21:43 ` Bill Atkins
2006-01-25 21:41 ` Alan Mackenzie
2006-01-25 23:19 ` Bill Atkins
2006-01-25 23:29 ` David Kastrup
2006-01-26 0:25 ` Thien-Thi Nguyen
2006-01-26 0:33 ` Lennart Borgman
2006-01-26 1:04 ` Thien-Thi Nguyen
2006-01-26 17:21 ` Drew Adams
2006-01-26 17:12 ` Drew Adams
2006-01-26 1:54 ` Miles Bader
2006-01-26 1:54 ` Miles Bader
2006-01-25 21:44 ` Lennart Borgman
2006-01-25 22:01 ` Alfred M. Szmidt
2006-01-25 22:07 ` Thien-Thi Nguyen
2006-01-25 22:16 ` Alan Mackenzie
2006-01-26 0:04 ` Karl Chen
2006-01-26 0:18 ` Luc Teirlinck
2006-01-26 4:33 ` Eli Zaretskii
2006-01-26 6:34 ` Miles Bader
2006-01-26 0:38 ` Thien-Thi Nguyen
2006-01-26 9:34 ` Alan Mackenzie
2006-01-26 13:28 ` Tomas Zerolo
2006-01-26 13:34 ` Thien-Thi Nguyen
2006-01-25 22:11 ` Luc Teirlinck
2006-01-25 22:35 ` Alan Mackenzie
2006-01-26 13:25 ` Tomas Zerolo
2006-01-25 22:51 ` Kim F. Storm
2006-01-25 23:31 ` Peter Whaite
2006-01-25 23:36 ` David Kastrup
2006-01-25 23:49 ` Mario Domenech Goulart
2006-01-26 17:46 ` Richard M. Stallman
2006-01-26 18:09 ` Luc Teirlinck
2006-01-26 19:55 ` Peter Whaite
2006-01-26 22:17 ` Kevin Rodgers
2006-01-26 22:29 ` Jose E. Marchesi
2006-01-26 23:19 ` Peter Whaite
2006-01-26 23:11 ` Jason Rumney
2006-01-26 23:53 ` David Kastrup
2006-01-26 17:46 ` Richard M. Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).