Re: Jobs assignments
24 years, 11 months
Jan Vroonhof
Jan Vroonhof
Ben Wing <ben(a)666.com> writes:
I think you can put in Sandra as primary for the FAQ.
> Bug Tracker
> Gunnar Evermann
> <gunnar(a)xemacs.org>
Does this alias work now?
Jan
- 1 participants
- 0 comments
Re: Jobs assignments
24 years, 11 months
Hrvoje Niksic
Hrvoje Niksic
Ben Wing <ben(a)666.com> writes:
> The jobs file I created has been up on the web site for some time
> under the heading "Dev team responsibilities".
>
> http://www.xemacs.org/Develop/jobs.html
Good work. I believe it should be updated as described below.
[ In the following comments, it goes unsaid that a job should be given
to someone iff he/she agrees to it. I didn't feel like repeating it
in every entry. ]
Jan stated clearly he had not the time to be the core patch tender, so
he should likely be removed. However, you can probably add me and him
as the "secondary" for that job.
Stephen Turnbull objected against the "Japanese Liaison" thing.
Please take that objection into account.
I did work on the LispRef manual. You can add me as the "secondary"
there. The same goes for the Internals manual and PROBLEMS.
Sandra Wambold should be added as the primary FAQ maintainer,
Christian Nybo secondary (until he returns to claim his position, or
to resign).
The "general design issues" job should be removed. Noone should claim
to be the primary person, and many more could be listed as secondary.
You could add Kyle Jones as secondary for the portable dumper.
Remove the "minimal tagbits" job. That work is done, and further
developments, when they happen, do not require a steady "job".
Windows support should include Adrian Aichner (and perhaps more
people) as secondary.
Redisplay should include Jan Vroonhof as secondary.
Customize should include me and Didier Verna as secondary.
- 1 participants
- 0 comments
Jobs assignments
24 years, 11 months
Ben Wing
Ben Wing
The jobs file I created has been up on the web site for some time under
the heading "Dev team responsibilities".
http://www.xemacs.org/Develop/jobs.html
But I get the feeling that many people listed in this file have not
looked at the file.
I am posting the file below. But please, if it's at all convenient,
follow the link above instead! The tables don't turn out at all below.
I ask that anyone who is contributing very much to XEmacs please scan
the file for their name, and see if the assignments make sense. Please
suggest any changes. The purpose of this file is not to rigidly force
people to do something they don't want, but to make it easier to figure
out who to contact in reference to a particular area, and to establish
some people in backup positions to try to ensure that no major area of
XEmacs gets wedged just because one person vanishes
ben
XEmacs JOBS
Current version: 11/11/99
Maintainer: Ben Wing <ben(a)xemacs.org>
XEmacs Review Board Members
The XEmacs Review Board has the authority to approve or
veto any patch
to XEmacs. Patches should be posted to
xemacs-patches(a)xemacs.org. If
someone vetoes your patch, you will receive e-mail from
them, stating the
veto but also describing exactly why the patch was
vetoed, and how it should
be changed in order to be acceptable. To qualify for
membership to the
Review Board, you should generally be someone who has
put a lot of work
into developing XEmacs for a long enough period of time
that you are aware
of the all of the basic ideas and issues in XEmacs and
the XEmacs
community.
The current members of the XEmacs Review Board are:
Andreas Jaeger
<aj(a)xemacs.org> Andy Piper <andy(a)xemacs.org> Ben Wing
<ben(a)xemacs.org> Didier Verna <didier(a)xemacs.org>
Hrvoje Niksic
<hrvoje(a)xemacs.org> Jan Vroonhof <jan(a)xemacs.org>
Jareth Hein
<jareth(a)xemacs.org> Jonathan Harris
<jonathan(a)xemacs.org> Kyle Jones
<kyle(a)xemacs.org> Martin Buchholz <martin(a)xemacs.org>
Michael
Sperber <mike(a)xemacs.org> Olivier Galibert
<galibert(a)xemacs.org>
Steve Baur <steve(a)xemacs.org> Vin Shelton
<acs(a)xemacs.org>
Primary Positions
Primary positions are important enough that they should
not allowed to
remain unfilled for any length of time. Detailed
descriptions of primary
positions appear below.
Position
Primary
Secondary
Beta Release
Maintainer
Martin Buchholz
<martin(a)xemacs.org>,
Steve Baur?
<steve(a)xemacs.org>
Binary-Kit
Coordinator
Jason Mastaler
<jason(a)xemacs.org>,
Stable Release
Maintainer
Vinnie Shelton
<acs(a)xemacs.org>
Meta-Maintainer
Ben Wing
<ben(a)xemacs.org>
Core Patch
Tender
Jan Vroonhof
<jan(a)xemacs.org>
Andy Piper
<andy(a)xemacs.org>,
Martin Buchholz
<martin(a)xemacs.org>
Package Patch
Tender
Andreas Jaeger
<aj(a)xemacs.org>
Martin Buchholz
<martin(a)xemacs.org>
CVS Manager
Jareth Hein
<jareth(a)xemacs.org>
Martin Buchholz
<martin(a)xemacs.org>
Postmaster
Jason Mastaler
<jason(a)xemacs.org>
Martin Buchholz
<martin(a)xemacs.org>
Webmaster
John S Jacobs Anderson
<jacobs(a)xemacs.org>
Marcus Thiessel
<marcus(a)xemacs.org>
Bug Tracker
Gunnar Evermann
<gunnar(a)xemacs.org>
Japanese Liaison
Stephen Turnbull
<stephen(a)xemacs.org>
[NOTE: I put a question mark by Steve Baur's name
because it is not clear
what his status is currently. Hopefully this will be
resolved soon.]
Documentation Positions:
All of the documentation is listed here. Some positions
are listed without
primaries. It would be really nice if there were people
actively maintaining
each of these documentation areas, but slippage here is
not so catastrophic.
Position
Primary
Secondary
Lisp Reference
Manual
Martin Buchholz
<martin(a)xemacs.org>
XEmacs User
Manual
Martin Buchholz
<martin(a)xemacs.org>
Internals
Manual
Martin Buchholz
<martin(a)xemacs.org>
Ben Wing
<ben(a)xemacs.org>
PROBLEMS
Martin Buchholz
<martin(a)xemacs.org>
FAQ
Martin Buchholz
<martin(a)xemacs.org>
NEWS
Hrvoje Niksic
<hrvoje(a)xemacs.org>
Martin Buchholz
<martin(a)xemacs.org>
README
Ben Wing
<ben(a)xemacs.org>
Martin Buchholz
<martin(a)xemacs.org>
Coding Projects
Position
Primary
Secondary
General design
issues
Ben Wing
<ben(a)xemacs.org>
Hrvoje Niksic
<hrvoje(a)xemacs.org>,
Kyle Jones
<kyle(a)xemacs.org>,
Olivier Galibert
<galibert(a)xemacs.org>
Coding
Standards
Martin Buchholz
<martin(a)xemacs.org>
Portable
Dumper
Olivier Galibert
<galibert(a)xemacs.org>
Minimal tagbits
implementation
Kyle Jones
<kyle(a)xemacs.org>
Windows
support
Andy Piper
<andy(a)xemacs.org>,
Jonathan Harris
<jonathan(a)xemacs.org>
Cygwin support
Andy Piper
<andy(a)xemacs.org>
Configure
support
Martin Buchholz
<martin(a)xemacs.org>
Mule
Ben Wing
<ben(a)xemacs.org>, Martin
Buchholz
<martin(a)xemacs.org>,
Olivier Galibert
<galibert(a)xemacs.org>,
Stephen Turnbull
<stephen(a)xemacs.org>
GUI support
Andy Piper
<andy(a)xemacs.org>
Redisplay
Andy Piper
<andy(a)xemacs.org>
Customize
Jan Vroonhof
<jan(a)xemacs.org>
GPM support
William Perry
<wmperry(a)xemacs.org>
The package
system
Steve Baur
<steve(a)xemacs.org>
Michael Sperber
<mike(a)xemacs.org>
Job Descriptions For Primary
Positions
Beta Release Maintainer
The beta release maintainer is the primary
maintainer for XEmacs, and
serves as the de-facto spokesman. His
responsibilities are (a) to put
out new beta releases on a regular basis, i.e. at
least every one to two
weeks (depending on activity), (b) to go out of
his way to be
responsive to e-mail sent to him and communicative
about and
interested in important issues in all major
aspects of XEmacs, and (c)
to decide when it's time to do an external
release. At this point, he is
responsible for initiating a code freeze and
assuming quasi-dictatorial
power over the development process, doing whatever
it takes to
ensure that a relatively stable, bug-free release
gets put out in a timely
fashion. If some important job is not getting done
during the critical
pre-release period, it is ultimately the duty of
the beta release
maintainer (in conjunction with the
meta-maintainer) to ensure that this
gets done, for example, by finding somebody else
who is willing to
take over this position, or (last resort) doing
the job himself. During
periods when an external release is not happening,
the beta release
maintainer goes back to being a relatively low-key
position,
responsible primarily just for putting out regular
beta releases. It is
imperative, however, that the beta release
maintainer continue to be as
responsive as possible to e-mail sent to him,
because he is the
de-facto spokesman and is looked up to as the one
providing overall
guidance for the project. If he fails to respond
to email, he will create
the impression that the entire project is in
disarray.
Binary-Kit Coordinator
The binary-kit coordinator is responsible for
organizing the
preparation, release, and distribution of
pre-compiled XEmacs
software based on the stable branch.
Stable Release Maintainer
The stable release maintainer is responsible for
putting out `stable'
releases of the code. These are generally small
updates to previous
external releases. Once a major external release
happens, the
development tree is forked, with one branch
becoming the stable
branch, the other the development branch. It is
from this stable branch
that stable updates happen and it is the stable
release maintainer's
responsibility to oversee this branch, decide
which patches belong in
this branch, and do whatever else is necessary to
put out a stable
update.
Meta-Maintainer
The meta-maintainer is responsible for defining
and managing the
separation of XEmacs duties into spheres of
responsibility or "jobs".
He maintains the list of jobs, which lists the
jobs, their descriptions,
and the current primary and secondary jobholder(s)
for each of these
jobs. (Generally, the primary actually does the
work of the job, but if
the primary becomes derelict in his duties, for
example by simply
disappearing and becoming unresponsive to email
contact, the
secondary steps in as the "acting jobholder",
until the primary returns
(along with assurances that he will not just
disappear again) or another
primary is found.) The meta-maintainer is also
responsible, along with
the beta release maintainer, for filling empty
positions and for noticing
when a job is not getting done. During pre-release
cycles, the beta
release maintainer may take the most active role
in filling positions;
during other periods, the meta-maintainer
primarily assumes these
duties.
Core Patch Tender
The core patch tender's responsibility is to make
sure that no patch to
the core of XEmacs falls through the cracks. Every
core patch posted
to XEmacs either needs to be approved and then
applied, or vetoed
with a suggestion for how to modify the patch so
that it is acceptable.
The core patch tender is responsible for making
sure that this happens.
If a patch is posted and is neither approved nor
vetoed within a
two-week period, the core patch tender needs to
step up and make
inquiries to determine what should be done with
the patch. If a patch is
posted and then vetoed with suggestions for
improvements, but no
improved patch is submitted within a week or so,
the core patch
tender needs to make inquiries to the patch
submitter to see if he can
finish up getting the patch up to snuff, and if
not, the reviewers need to
be contacted again.
Package Patch Tender
The package patch tender's job is analogous to the
core patch
tender's, except that it applies to the Lisp
packages that are, in some
sense, external to XEmacs itself. His job may be
complicated by the
fact that packages may have active maintainers who
may not be
directly involved in XEmacs development. In that
case, he may need
to track down the active maintainer and try to get
him to accept the
patch. The package patch tender also needs to
create and maintain a
list of all the packages that are part of the full
XEmacs development
tree. For each package, this list should specify
the package's home
page (if any), the maintainer and his contact
address, any mailing lists
devoted to the package, the number of the latest
release and where to
get it, the corresponding XEmacs package release
number, and (if the
information is available) a subjective judgment as
to how well the
package is currently being maintained, from 0
(package is obsolete, no
one has maintained it in years) to 5 (package
contains an active,
well-organized development effort with regular
releases, mailing lists, a
web site, etc.).
CVS Manager
The CVS manager is responsible for all CVS issues
related to
XEmacs.This includes, for example, the CVS trees
for the core and
thepackages, and the CVS web interface. This
includes the important
but thankless task of doing backups.
Postmaster
The mailing list manager is responsible for
maintaining the XEmacs
mailing lists.
Webmaster
The webmaster is responsible for maintaining the
www.xemacs.org
web site.
Bug Tracker
The bug tracker is responsible for keeping track
of all the bugs that
have been posted anywhere, either to xemacs-beta,
comp.emacs.xemacs, or similar sources. Properly
speaking, they need
to be kept in a database, assigned priorities,
severities and owners,
and managed in the standard way that bugs are
managed.
Unfortunately, we don't currently have such an
infrastructure, so it's the
current responsibility of the bug tracker to keep
track of the bugs in
any way possible (e.g. just a simple list), with
the number one cardinal
rule being: NO BUG MAY FALL THROUGH THE CRACKS.
Every bug that gets reported through any standard
means needs to end
up on the list, along with as much information as
possible from the bug
report: The name of the person reporting the bug,
the version number
of XEmacs being run, the circumstances and
behavior of the bug, etc.
etc. etc. The secondary responsibility of the bug
tracker is to
investigate a workable bug-tracking system for
XEmacs. I know that
the Samba project has such a system in place, so
we should just be
able to use theirs, for example.
Japanese liaison
The Japanese liaison is responsible for assisting
in communications
between Japanese and non-Japanese XEmacs
developers. Very few
XEmacs developers are fluent in both English and
Japanese.
--
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You _will_ get a response, but please be
patient.
If you need an immediate response and it is not apparent in your
message,
please say so. Thanks for your understanding.
- 2 participants
- 1 comments
Re: [Bug 7694] Changed - docstrings broken in xemacs-mule and other binaries
24 years, 11 months
Jens-Ulrik Petersen
Jens-Ulrik Petersen
bugzilla(a)bugzilla.redhat.com <bugzilla(a)bugzilla.redhat.com> writes:
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=7694
>
> Version: 6.1
> Platform: i386
> OS/Version: Linux
> Status: ASSIGNED
>
> > Redhat Powertools comes with several xemacs binary packages (xemacs,
> > xemacs-mule, xemacs-noX).
> >
> > Evaluating
> >
> > (describe-function 'string-match)
> >
> > in "/usr/bin/xemacs" gives the expected result, but in
> > "/usr/bin/xemacs-mule" (and also "/usr/bin/xemacs-noX" I think) the
> > docstring is broken giving garpled and incorrect information.
> >
> > I have seen the same problem with JRPM60 xemacs packages, but haven't tried
> > xemacs rpms from many other distributions.
> >
> > If this isn't a known problem, then maybe some people on the xemacs-beta
> > list could help the packagers with sorting out this annoying problem out.
> >
> > Cheers, Jens
> > <jens-ulrik.petersen(a)nokia.com>
>
> ------- Additional Comments From timp(a)redhat.com 12/09/99 11:37 -------
> OK. I wasn't aware of this problem (I'm not an xemacs/emacs
> user). Can you tell me exactly what was done so that I can reproduce
> the problem and get with some folks here who use xemacs?
>
> Tim
In fact to see the problem it is sufficient to compare the output of
(a) /usr/bin/xemacs-21.1.8 --help
and
(b) /usr/bin/xemacs-mule --help
(and you can surely confirm that `/usr/bin/xemacs-noX --help` gives
the same problem and xemacs-static too).
Case (a) gives correct output for --help, but for (b) you see the
garbled output from the "-help" line onwards.
The problem is that the different XEmacs binaries ("xemacs-21.1.8",
"xemacs-mule", "xemacs-noX", and "xemacs-static") are using the same
"/usr/lib/xemacs-21.1.8/i386-redhat-linux/DOC" file, whereas a
different "DOC" file is needed for every different binary.
Looking at the Install section of "xemacs.spec" makes this clear:
---- Start of included text -----------------------8<--- cut here -------------
%install
rm -rf $RPM_BUILD_ROOT
cd building
make install \
prefix=$RPM_BUILD_ROOT/usr \
lockdir=$RPM_BUILD_ROOT/var/lock/xemacs -C $RPM_ARCH-linux
for i in static X11 mule noX ; do
install -m 755 $RPM_ARCH-linux-$i/src/xemacs $RPM_BUILD_ROOT/usr/bin/xemacs-$i
---- End of included text -------------------------8<--- and here -------------
Proper installation as intended by the XEmacs developers only occurs
for the standard xemacs binary build, for the other builds the
binaries are just copied over by hand (although they have their own
DOC files in their build "etc/" directories)...
How to solve this? The easiest way from the users/installers point of
view would be (see also my PS below) to make the separate executable
packages conflict with each other and each containing their own DOC
file (and "config.values" file too btw).
To fix things keeping the current status quo of multiple executable
packages, needs a little more thought, and would probably be best
fixed by the XEmacs developers. I used to be an XEmacs
developer/beta-tester, but unfortunately don't have time for that any
more, so I'm cc'ing this to the xemacs-beta list and the maintainer of
the JRPM60 xemacs packages to get their feed back too. I guess one
solution would be to allow separate DOC files for each xemacs
executable: this would require some (I think) minor changes to the
xemacs sources and "src/Makefile", something like an option to add a
given suffix to the xemacs executable name and the corresponding "DOC"
and "config.values" files.
Sorry this become so long.
Best wishes, Jens
ps I feel you have too many XEmacs packages: in my opinion just the
basic xemacs, xemacs-mule (but with tty support please) and (?) maybe
an xemacs-static should be quite sufficient for the majority of users.
However I would recommend separating "/usr/bin/xemacs-%version" from
the general xemacs package, to give people a decent choice. Eg
personally I just need xemacs-mule with tty support, and I imagine
many sites/users would be content with just installing and using one
xemacs binary not five. (I know there are problems with the mule
current support in a tty: I don't use mule in a tty, I just don't want
to have to fire up a different binary when I'm in a console.)
- 1 participants
- 0 comments
Re: Some small bugs in b22 and b20
24 years, 11 months
Hrvoje Niksic
Hrvoje Niksic
Raymond Toy <toy(a)rtp.ericsson.se> writes:
> I do have two summary functions.
[...]
> If I set vm-flush-interval to 90 (the default), profile-key-sequence
> on "n" still says vm-run-user-summary-function still says 89%.
Some clarification about the profiling support:
* It has no notion of "call graph". If it says 89% time is spent in
function X, then it's really in function X, i.e. the byte-codes
within that functions. It does not include the time spent in
children that are Lisp functions.
* It is not reliable for small timings and functions where time is
short, because it is based on a profiling signal. The "call count"
thing is reliable, though.
* It is completely unreliable if you compile with error-checking.
That is, it gives you the correct numbers, but the results can be
completely different when you compile without error-checking. So if
you profile seriously, turn off error-checking when building XEmacs.
* It knows nothing of C builtins. Time spent there simply counts in
the Lisp function that called them.
- 1 participants
- 0 comments
New Athena widget configuration (was Re: Problem with `configure --with-sound')
24 years, 11 months
Daniel Pittman
Daniel Pittman
On 9 Dec 1999, Daniel Pittman <daniel(a)danann.net> wrote:
> On 08 Dec 1999, Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote:
>
>> Daniel Pittman <daniel(a)danann.net> writes:
>>
>>> Right while I was in the middle of hacking up the configure stuff as
>>> well in an effort to fix the Athena3D lossage[1][2].
>>
>> Yippee!
[...]
Right. Currently you can select the both `athena` and `athena3d' when
selecting the type of widgets, scrollbars and dialogs. Configure then
does a bit of magic to try and get the right library/header combination.
In place of this, I propose:
--with-widgets and friends now take only `athena' as an argument. This
specifies that an Athena widget set is desired, but not which one.
(Eventually--backward compatibility notes below)
Configure looks for all the Athena libraries and headers, working out
which ones are Athena and which ones are Athena3D. This bit is already
working on my box. :)
The option `--with-athena' is available to specify the preferred Athena
widget set. This takes a range of values such as `flat' or `3d' or
`next' that specify what libraries to prefer.
Without this option being specified, the user gets libXaw.so preferred,
with the flat or 3d headers according to the 3d-ness of libXaw.so. This
retains the current behavior of `--with-widgets=athena' -- no surprises
to people who don't pay attention.
In this vein, `--with-widgets=athena3d' would be the same as the new
`--with-athena=3d' and `--with-widgets=athena' for backward
compatibility.
Finally, for the developers, we spit out the following values:
HAVE_ATHENA_HEADER_PATH=X11/Xaw (or X11/Xaw3d or whatever is the right
path)
HAVE_ATHENA_3D=yes (if and only if the chosen Athena is a 3D Athena,
else undefined)
HAVE_ATHENA_VARIANT=chosen variant (flat or 3d or next...)
We also add the relevant Athena -l... to the link settings.
The only real option I can think of aside from this is to clean up the
current `--with-widgets=athena(3d)?' stuff, then add `widgets=nextaw'
(since that's why I started this thang :)
That seems ugly if someone wants to use Xaw95 or XawXpm or something
though. Lots and lots of options.
Daniel
--
Quid sit futurem cras fuge quaerere
-- Horace
- 1 participants
- 0 comments
Re: Configure needs to be picker about Enheavied Sound Demon
24 years, 11 months
Daniel Pittman
Daniel Pittman
On 09 Dec 1999, Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote:
> "Daniel Pittman" <daniel(a)danann.net> writes:
>
>> I sent in a bug report about this in unstable (erm, potato) for this
>> and was told that `esd-config' is in esound-common to avoid
>> duplicating it in both the normal and alsa libesd-dev packages.
>>
>> This is a real PITA, but I don't know if the problem will go away.
>
> Did you reopen the bug with the comment that they should make an
> 'esound-dev-common' then?
>
> Potato has not been released yet. There is still time to do it
> properly.
Checking in the BTS, it seems that they have not closed the bug and are
working on a fix. So, Debian will fix it. Nifty :)
Daniel
--
Every man who knows how to read has it in his power to magnify himself, to
multiply the ways in which he exists, to make his life full, significant and
interesting.
-- Aldous Huxley
- 1 participants
- 0 comments
Drag-N-Drop
24 years, 11 months
A.J. Rossini
A.J. Rossini
I've been away from development here for a while, but what's the
current situation with respect to XEmacs and either GNOME or KDE
drag-n-drop?
best,
-tony
--
A.J. Rossini Research Assistant Professor of Biostatistics
Center for AIDS Research/HMC Biostatistics/Univ. of Washington
Box 359931 Box 357232
206-731-3647 (3693=fax) 206-543-1044 (3286=fax)
rossini(a)u.washington.edu rossini(a)biostat.washington.edu
http://www.biostat.washington.edu/~rossini/
- 1 participants
- 0 comments
Re: More ESD ./configure bogosity
24 years, 11 months
Raymond Toy
Raymond Toy
>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
Jan> Raymond Toy <toy(a)rtp.ericsson.se> writes:
>> Why can't we reliably detect NAS? Isn't the existence of a few
>> include files and libaudio enough?
Jan> I don't know really. Note that there a lot of audio libraries named
Jan> libaudio so would have to do some magic with nm to find out what kind
Jan> it actaully is.
Why would you have to do that? Wouldn't configure just try to compile
something like
#include <appropriate headers>
main()
{
AuSoundPlayFromFile(<appropriate args>);
}
to see if this is NAS. We'd have to pick some appropriate function,
of course.
Ray
- 1 participants
- 0 comments
Re: Some small bugs in b22 and b20
24 years, 11 months
Raymond Toy
Raymond Toy
>>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes:
Kyle> Raymond Toy writes:
>> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes:
>>
>>
Hrvoje> Type `M-x profile-key-sequence', then `n', and then `M-x
Hrvoje> profile-results'. XEmacs should tell you where most of the time was
Hrvoje> spent.
>>
>> Thanks for that hint! I didn't even know such a thing existed.
>>
>> Anyway, with vm-flush-interval set to T, what happens is that more
>> than half of the time is spent in running vm summary function. I
>> wonder why that is.
Kyle> Which VM summary function?
Sorry, it was vm-run-user-summary-function, and the current run says
89% of the total time is spent here.
I do have two summary functions. vm-summary-function-L computes the
number of lines in the message via (count-lines-region), and
vm-summary-function-C computes the size of the message via (-
(point-max) (point-min)).
If I set vm-flush-interval to 90 (the default), profile-key-sequence
on "n" still says vm-run-user-summary-function still says 89%.
I think I need to some more testing to get this all straightened out.
Ray
- 1 participants
- 0 comments