armedbear-j-devel — J Development Mailing List

[j-devel] This morning's snapshot

[Peter G. <pe...@ar...>]

This morning's 0.16.3+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot finishes a bit of cleanup to remove unnecessary repaints
in the sidebar tree, both in Java mode and in directory buffers.

In addition, this morning's snapshot fixes a NullPointerException in
FTP directory buffers (and possibly elsewhere too) introduced
yesterday by an earlier version of the self-same cleanup code.

-Peter

[j-devel] Odd display problems under Mac OS X 10.2

[Peter G. <pe...@ar...>]

Bug 602930:

    I just upgraded my Mac to OS X 10.2, and noticed odd display
    problems (seen in both J 0.16.1 and after I upgraded to 0.16.3).
    The problem is the addition of an extra "space" when typing
    scrolling or cutting or pasting. Sometimes upon paste, the buffer
    is corrupted with extra characters. 

First of all, let me begin my saying that I don't have a machine in my
personal collection that's capable of running Mac OS X. On relatively
rare occasions I do have access to such a machine, but that's nothing
to count on. So I can't really fix Mac-specific bugs myself.

That said, I'm aware that even with 10.1, there were apparently some
problems with j related to using specific keys; I don't know the
details. Apparently with 10.2 there may be some additional problems.
Normally I would say that if a problem with an application first
appears when you go from one version of the OS to another, it's a
problem with the OS, but in this case I'm not sure j ever worked
quite right to begin with.

It's likely that there are relatively easy workarounds for most if not
all of these problems. If you're so inclined, have at it, and send me
patches. I'll certainly be glad to help, as best I can without the
right hardware.

On a related note, I'd very much like to move j's code base to Java
1.4, and the only thing that's holding me back is the fact that 1.4 is
not yet available for OS X. If you have any idea when this deficiency
might be remedied, please let me know.

For that matter, if requiring Java 1.4 would be a hardship for you
for some other reason, please let me know that, too.

Thanks for your support.

-Peter

[j-devel] Mail cleanups

[Peter G. <pe...@ar...>]

This morning's 0.16.3+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

The command sortByThread was badly named. Threads are not a way of
sorting mailboxes, exactly; they're a way of grouping messages. The
sibling messages in a thread can (in theory) still be sorted in
various other ways (by sender, by date sent, by date received, by
size, etc.).

So the command sortByThread has been replaced by the command
toggleGroupByThread, which does what its name suggests. The View menu
in mailbox mode has been updated accordingly.

The command sortByDateSent has also been removed. Currently j doesn't
support any sort order other than date sent, so there's really nothing
for sortByDateSent to do.

To sum up, sortByThread (in previous versions) has been replaced by
checking the "Group Messages By Thread" checkbox; sortByDateSent (in
previous versions) has been replaced by unchecking the "Group Messages
By Thread" checkbox. toggleGroupByThread is the command underneath the
aforementioned checkbox; it's not mapped to any keystroke by default
but you can invoke it via Alt X.

In the last snapshot, mailboxes.xml was erroneously placed in ~/.j;
this snapshot moves it into ~/.j/mail where it obviously belongs.

In addition, the caching of both headers and actual messages in IMAP
mailboxes now uses the canonical name of the mailbox, as is obviously
correct. (In previous versions a slightly less exact variant of the
canonical name was used.) This change should be transparent to the
user (the header cache will be rebuilt, but the old message cache
should be preserved; it's really just a matter of updating the
catalogs).

There's still no UI for setting mailbox-specific properties. I've been
distracted by the related issue of configuring "accounts", which are
essentially a way of grouping together all the mailboxes on a
particular server for a particular user (although there are some
additional issues). This is the way real mail clients work.

J has traditionally approached mail as just another URL, so to speak,
which offers a certain amount of flexibility but is awkward if you
have 400 folders on some IMAP server and you want to set up properties
that really should be global for that server, rather than local for
each of the 400 mailboxes (where mailbox == folder).

So at some point in the future j will let you define an account, which
is a named object with various obvious attributes like server, port,
user name, type (IMAP or POP), etc., and some less obvious ones like
tunnel configuration.

Once you have defined an account, you can open it (yes, the account),
which will present a view of the account's default inbox, and also (in
the case of IMAP, which is really the only interesting case) let you
browse the folder hierarchy on the server in question, just like
downtown.

J will also use the account information, if it's present, to set up
defaults for mailbox-specific properties if you open (via URL) a
mailbox that "belongs" to the account in question. If a property is
set at the mailbox level, so be it, but if it's not, j will look for
the same property at the account level and use that as a default if
possible. (This will work the same way buffers and modes work today:
if a property, like tabWidth, is set at the buffer-specific level, it
overrides the mode-specific default.)

The idea is that accounts will be helpful, if you like that way of
working and bother to set them up, but they won't be required, and
they won't be obtrusive if you have simple needs and don't want to
deal with them.

In any case, support for accounts is currently just a plan, and plans
are cheap. A user interface for setting mailbox-specific properties is
needed in any case and will be forthcoming shortly. (Just to be clear,
the UI I'm talking about is basically a couple of new Alt X commands,
not anything as extravagant as a dialog box.)

Finally, in web mode, the command copyLink has been added, available
via Alt X. copyLink copies the link (i.e. href) at the current
location of the caret to the system clipboard (and to j's kill ring),
so you can paste it after "wget " in a shell buffer... ;)

Thanks for your support.

-Peter

[j-devel] Persistent mailbox-specific properties

[Peter G. <pe...@ar...>]

This morning's 0.16.3+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot introduces persistent mailbox-specific properties.

There's no UI for this feature yet, so the only way you can see it in
action is to open your favorite mailbox, invoke sortByThread (or
select the "Sort by Thread" radio button on the View menu), then close
the mailbox, and (to prove persistence across sessions) exit j.

Then restart j and re-open the same mailbox and it will come up
automatically in a threaded view.

No big deal, you say, but j couldn't do that yesterday... ;)

And more importantly, the infrastructure is now in place to set -any-
mailbox-related property on a per-mailbox basis.

UI coming soon.

Thanks for your support.

-Peter

[j-devel] Attachments

[Peter G. <pe...@ar...>]

This morning's 0.16.3+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot fixes a bug introduced yesterday by the header
beautification code that prevented you from viewing or saving
attachments correctly in message buffers.

Today's snapshot uses an Annotation object to associate the MimePart
in question with the relevant line in the "Parts/Attachments" section
of the message buffer, which is a much more robust approach than the
one used by the old code, which was dependent on the way the buffer
was formatted (which is why it broke with the introduction of
beautified headers).

By request, you can now use Enter, as well as 'v', to view the
attachment on the line containing the caret.

Thanks for your support.

-Peter

[j-devel] Beautified headers

[Peter G. <pe...@ar...>]

This evening's 0.16.3+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

By request, this snapshot adds support for beautified headers in
message mode.

This means that by default, when you're reading mail, message headers
now appear with the header names right-justified, and in most cases
the header values are wrapped at 74 columns. ("In most cases" means
the wrapping happens deliberately with the address lists for "To" and
"Cc", which are most likely to have problems with line length; the
subject, date and "From" header are probably short enough to begin
with.)

Headers are beautified by default. If you like your headers raw, add
this line to ~/.j/prefs:

    beautifyHeaders = false

If you turn on raw mode (Shift R, messageToggleRaw) or full headers
('h', messageToggleHeaders), you'll see the raw headers even if
beautifyHeaders is true.

In addition, j now slavishly emulates Pine rather than mutt and no
longer automatically prepends "-- \n" to your signature (if any). If
you want "-- \n" prepended to the actual text of your signature, add
such a line to ~/.signature (or whatever). It's a good idea, just not
the law.

Thanks for your support.

-Peter
-- 
"It is now the year 2002.  Nobody should be writing POP3 clients any
more." -- Mark Crispin

[j-devel] Signature file support

[Peter G. <pe...@ar...>]

This morning's 0.16.3+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

By request, this snapshot adds support for signature files. On Unix,
~/.signature is picked up by default. On non-Unix platforms, or if
you'd prefer a different file, you can add a line to ~/.j/prefs, e.g.:

    signature = /home/peter/my_funny_signature

In addition, I fixed a little POP3 breakage caused by yesterday's
sorting and threading adventures.

Thanks for your support.

-Peter
-- 
"It is now the year 2002.  Nobody should be writing POP3 clients any
more." -- Mark Crispin

[j-devel] IMAP header cache problem (now fixed)

[Peter G. <pe...@ar...>]

Yet another development snapshot:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This one fixes a problem with the IMAP header cache that was
introduced in this morning's snapshot.

The symptom of this problem was that messages appeared to vanish from
your IMAP mailbox, a disconcerting phenomenon indeed.

In actual fact, the messages didn't vanish at all, and if you deleted
your IMAP header cache (rm ~/.j/mail/imap/*) and tried again, all
would be well, until you closed the mailbox, at which point the header
cache bug would come into play again the next time you opened it.

In any case, this bug is fixed in tonight's snapshot, although if
things still don't look right you may have to delete your header cache
one last time (rm ~/.j/mail/imap/*) and re-open the mailbox so that j
can re-synchronize things.

This was strictly a header caching issue, and there was never any real
risk of damage to the messages in your mailbox on the IMAP server, so
this problem seemed worse than it was, but even so it was bad enough.

Sorry for any inconvenience.

-Peter

[j-devel] Persistent placement of preview pane

[Peter G. <pe...@ar...>]

This morning's 0.16.3+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

Starting with the 0.16.3+ snapshot series, Enter has been mapped by
default in mailbox mode to mailboxReadMessageOtherWindow, which (as
its name suggests) displays the message in question in another window,
splitting the current window if necessary. This second window is
roughly analogous to what Outlook and Evolution call a preview pane.

By default, the original window is split in half, which may not be
exactly ideal. You can, of course, adjust things by dragging the
window divider up or down, and starting with today's snapshot, j
remembers the position of the window divider and restores it correctly
the next time it is necessary for mailboxReadMessageOtherWindow to
split the window, so your preview pane will continue to be whatever
size you've set, even across sessions.

If, in the interim (i.e. while the preview pane is closed), you change
the size of j's main window, the preview pane divider will be
repositioned, at the next invocation of mailboxReadMessageOtherWindow,
at the same relative height as before (relative, that is, to the total
available height within the editor frame).

This remembering of the divider position only applies to the preview
pane and mailboxReadMessageOtherWindow. Other commands that split the
window continue to split it in half, and adjustments to the divider
position in other split-window situations are not remembered.

You can use the command escape, mapped by default to the Escape key,
to dismiss the preview pane, leaving a full-height view of the mailbox
again.

(The command mailboxReadMessage, which was mapped by default to Enter
in mailbox mode prior to the recent snapshot series, is now mapped to
Ctrl Enter, so if you prefer a full-height message buffer, Ctrl Enter
is your friend.)

Thanks for your support.

-Peter

[j-devel] This morning's snapshot

[Peter G. <pe...@ar...>]

This morning's 0.16.3+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot features a much faster and more accurate version of
sortByThread (which, BTW, is misnamed, but that's not important now).

It's about 30 times faster than the version in 0.16.3, and it does a
much better job of the actual threading, per the imapext-thread
Internet Draft.

By request, the indentation increment for threaded messages is now 2
instead of 1.

At the top level, the first orphan message in a sibling set is now
indicated by a '-' followed by a space at the beginning of the subject
column. (Orphan messages are messages that have a parent, but whose
parent is not actually in the mailbox.) Evolution promotes such
messages to the top level and treats their siblings as their children,
but this approach is not strictly correct. The "- " prefix is probably
not the last word in the rendering of this situation... ;)

On a brighter note, J does correctly recognize that

    Re: [V4L] Re: [RFC] alternative kernel multimedia API

and

    Re: [livid-gatos] [RFC] alternative kernel multimedia API

represent the same base subject, which is more than can be said of
either Mutt or Evolution, but maybe they have their reasons...

Finally, in JavaScript mode findTagAtDot now ignores the arity
of the expression at dot, since you really can't trust arity in
JavaScript.

Thanks for your support.

-Peter

[j-devel] Re: UI Option to stop multiple-file search

[Ed S. <ed...@ee...>]

I think you're right, and I'll be happy to use ESC. But maybe a small 
alert down in the status bar, "Press Escape to stop search" ?

Peter Graves wrote:

>Feature Request 600912:
>
>    Sometimes multiple-file searches take longer than you'd like, or
>    you see what you're looking for and would like to stop the search
>    before it scrolls offscreen.
>
>    Solution: A one-button dialog box that appears in the middle of
>    the split-window *opposite* the search results window, that says
>    "Stop Search" or some such.
>
>As things stand, you can stop a search in progress by hitting Escape
>(which is mapped by default to the command "escape" in all modes).
>
>After you hit Escape once to stop the search, hitting Escape a second
>time dismisses the search results window.
>
>If you have dismissed the search results window, Ctrl L (listFiles)
>brings it back.
>
>A dialog box with a button would work too, but j tends to use Escape
>for this sort of thing, and I think Escape has the right feel.
>
>The real problem is that this use of Escape is totally undiscoverable;
>I've made a note to update the documentation of findInFiles.
>
>In general, j uses Escape in many situations to cancel an operation
>or dismiss a transient buffer. It's a bit quirky, since the behavior
>is very context-dependent, but once you get used to it, it's pretty
>intuitive. Which is not to say it can't be improved upon... ;)
>
>Comments?
>
>-Peter
>
>  
>

[j-devel] UI Option to stop multiple-file search

[Peter G. <pe...@ar...>]

Feature Request 600912:

    Sometimes multiple-file searches take longer than you'd like, or
    you see what you're looking for and would like to stop the search
    before it scrolls offscreen.

    Solution: A one-button dialog box that appears in the middle of
    the split-window *opposite* the search results window, that says
    "Stop Search" or some such.

As things stand, you can stop a search in progress by hitting Escape
(which is mapped by default to the command "escape" in all modes).

After you hit Escape once to stop the search, hitting Escape a second
time dismisses the search results window.

If you have dismissed the search results window, Ctrl L (listFiles)
brings it back.

A dialog box with a button would work too, but j tends to use Escape
for this sort of thing, and I think Escape has the right feel.

The real problem is that this use of Escape is totally undiscoverable;
I've made a note to update the documentation of findInFiles.

In general, j uses Escape in many situations to cancel an operation
or dismiss a transient buffer. It's a bit quirky, since the behavior
is very context-dependent, but once you get used to it, it's pretty
intuitive. Which is not to say it can't be improved upon... ;)

Comments?

-Peter

[j-devel] 0.16.3

[Peter G. <pe...@ar...>]

0.16.3 is up:

    http://armedbear-j.sf.net/

The corresponding snapshot is in the usual place:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

0.16.3 is the release formerly known as 0.17.0. ;)

This is exactly the same code I planned to release as 0.17.0, but
upon further review it didn't seem like a 0.17.0.

So 0.17.0 will come a bit later, and be a bit different...

The next project I do will have a simpler version numbering scheme, so
I can actually understand it.

Thanks for your support.

-Peter

[j-devel] 0.17.0 release candidate

[Peter G. <pe...@ar...>]

Today's 0.16.2+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot is (more or less) a release candidate for 0.17.0.

It contains a number of bugfixes and minor improvements, to wit, in no
particular order:

- When you eventually send a message that has at some point been saved
as a draft, the draft of the message in question is now automatically
deleted from the drafts folder.

- In mailboxes, the date is displayed in "MMM dd yyyy" format (instead
of "MMM dd HH:mm" format) if the message in question is more than 6
months old (approximately), as is the case for quite a few messages in
my drafts folder. Slavishly emulating ls...

- In previous versions, with Java 1.4.1, if you did Alt B to set focus
to the buffer list (so you could use the keyboard to scroll around in
the list, maybe close some buffers, etc.), when you subsequently hit
Escape to return to the edit window, focus was lost.

This bug is now fixed, and the code behind Escape, which in previous
versions contained an elaborate hack that seemed necessary at the
time, has been simplified considerably. I've tested the new code with
the latest versions of IBM 1.3.1, Blackdown 1.3.1, Sun 1.4.0, Sun
1.4.1-beta and Blackdown 1.4.1 beta; all seems to be well.

In addition, if you do Alt B and use the Delete key to close the
-current- buffer, the edit window now repaints immediately, as it
should. (In previous versions it tended not to repaint at all.)

- With the last 0.16.2+ snapshot or two, when you deleted a message in
a mailbox, the caret was advanced correctly to the next line, but the
current line highlighting was not properly painted for the new current
line. Fixed.

- Keywords are now configurable in BeanShell mode, as in all other
modes. (In previous recent versions keywords weren't highlighted at
all in BeanShell mode.)

Thanks for your support.

-Peter

[j-devel] This morning's snapshot

[Peter G. <pe...@ar...>]

This morning's 0.16.2+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot fixes a few minor bugs not related to mail:

- In Java mode in 0.16.2, if there were multiple interface names
following "implements", all but the last were incorrectly added to the
tag list as fields. Fixed.

- The Java tagger in 0.16.2 reported the visibility of public,
private, or protected methods incorrectly if the method in question
immediately followed a field declaration with an initializer, e.g.

    private static Stack markers = new Stack();

    public void pushPosition()
    {
    }

In this situation pushPosition() would be incorrectly reported to have
package (rather than public) visibility. Fixed.

- cvsCommit didn't refresh the display properly when the CVS checkin
buffer went away if the window wasn't split at the time. Fixed.

And finally, in a mail-related improvement, sortByThread now handles
messages better when their subject begins with "Re: Re:" (or "Re:Re:
Re:", etc.); j now strips all occurrences of "re:", regardless of
case, with or without trailing whitespace, when trying to find the
parent message. sortByThread is still not perfect, but it's getting
better...

The current plan is to release 0.17.0 in the next few days, prior to
embarking on mailbox-specific properties, which might take a while.

Thanks for your support.

-Peter

[j-devel] delete, undelete, and expunge in the drafts folder

[Peter G. <pe...@ar...>]

This morning's 0.16.2+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

The commands delete (mapped by default to 'd'), undelete ('u') and
expunge ('$') now work in the drafts folder.

I'm of two minds (maybe even more) about whether send() should
summarily delete the sent message from the drafts folder, if the sent
message came from there. The user did save it, after all...

If you have any thoughts on that subject please let me know.

Thanks for your support.

-Peter

[j-devel] Saner handling of postponed messages

[Peter G. <pe...@ar...>]

Today's 0.16.2+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot introduces a real glow-in-the-dark, lift-the-flap
"drafts" folder.

For a long time, if you exited j while you were in the midst of
composing a mail message, the composition buffer would be restored as
part of the saved session when j started up again. This happened
automatically because there was an actual file backing the message, so
the buffer was restored just like any other file-backed buffer. J knew
the buffer should be a mail composition buffer because the file
backing it was in a special directory (~/.j/mail/unsent).

So postponed messages weren't a total disaster. But if you made the
mistake of closing the composition buffer after you saved it, there
was no obvious or documented way to re-open the saved message again
later so you could finish it and send it on its way.

Starting with the current snapshot, you can simply enter "drafts" in
the location bar, and you'll get a mailbox view of the long-hidden
drafts folder. (If you're looking at some other mailbox, you can also
get to the drafts folder by clicking on "drafts" under "Local Folders"
in the sidebar tree.)

At the moment, all you can really do in the drafts folder is hit
Enter to open the message on the current line. If you do that, you'll
get a mail composition buffer which will let you continue working on
the message in question and eventually send it.

For no good reason, j has never deleted any messages from the drafts
folder, even if you did subsequently manage to send them off, and the
current snapshot is no different in this respect, although the right
thing to do is clearly to delete the message after it has been sent,
and I'll be implementing that functionality shortly.

In fact, with the current snapshot, you can't even delete a message
from the drafts folder manually; I'll be implementing delete and
expunge for the drafts folder in the near future too.

Finally, the location of the drafts folder has changed; it's now
~/.j/mail/local/drafts, rather than ~/.j/mail/unsent. The current
snapshot runs a bit of code at startup to move your unsent messages to
the new place and remove the obsolete ~/.j/mail/unsent directory. This
code has worked fine for me on two different machines, but if you have
unsaved messages that are important to you, you might want to back up
~/.j/mail/unsent before running the new snapshot, just in case.

Thanks for your support.

-Peter

[j-devel] Bug 596241 (Bug in brace highlighting)

[Peter G. <pe...@ar...>]

Mike reports that with a certain file, matching brace highlighting
doesn't work for the opening brace of the class or the opening brace
of a particular method.

And he continues:

    One of the odd bits is that if a line is deleted from the method,
    brace highlighting works fine again for the method definition line.

Which is an important clue.

By design, the code to highlight matching braces, brackets and
parentheses is subject to an arbitrary limit of 100 lines. If the
matching brace is further away than that, all bets are off. (See
Display.java, line 420.)

The reason to do this is that if the brace in question actually has no
match (as frequently does occur in practice), without an arbitrary
limit the search might continue all the way to the beginning or end of
the file. If the file is large, this might take longer than we want to
allow. The brace matching code runs in the display's paintComponent()
method, and we don't want paints to be slowed down by an unmatched
brace. The idea is that 100 lines should be enough to highlight the
matching brace if it's actually visible on the current screen.

Now, I realize that one of the nice things about the highlightBrackets
preference, as opposed to the highlightMatchingBracket preference, is
that you get useful information just by looking at the brace your
caret is currently on: if it's highlighted, you know that it at least
matches something.

Unfortunately, because of the 100 line limit, if the brace your caret
is on is not highlighted, you can't definitively conclude that it's
unmatched. (This is really only a problem with a brace; 100 lines
should be more than enough for brackets and parentheses.)

In any case, I'll leave this bug open for a few days, but unless
someone comes up with a compelling argument in the other direction, I
plan to close it without changing anything.

It might make sense to increase the limit at some point in the future,
when hardware is faster and no one will notice.

Thanks for your support.

-Peter

[j-devel] Bugs 591218 and 592658

[Peter G. <pe...@ar...>]

Bugs 591218 and 592658 are fixed in tonight's development snapshot:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

While I was at it I fixed an even more annoying Java mode indentation
bug that led to bizarre and incorrect results if a "//" comment
started in the first column of the line after an opening brace or in
the first column of the line after a "case" or "default" line in a
switch statement. This bug tended to show up for me if I used F11 to
comment out the first line of a method and then pasted another block
of code below it; the indent-after-paste was way off.

In addition, setting raw mode for a mailbox (Shift R) now works
correctly with cached IMAP messages.

This is not quite a release candidate for 0.16.2, but I'm getting very
near the end of my list (not to mention the end of my rope).

Thanks for your support.

-Peter

[j-devel] More mail-related improvements

[Peter G. <pe...@ar...>]

This morning's 0.16.1+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

For IMAP, the check mail background task now just polls via NOOP,
which is the very most efficient thing to do (short of IDLE, which is
an optional extension).

If you do Shift G in an IMAP mailbox (mailboxGetNewMessages), j will
actually request the headers ("uid fetch n:*"), even if it thinks it
doesn't have to. This is a tad less efficient in the no-new-messages
case, but it's a way to forcibly re-synchronize things if you think j
is confused about the message count. (Such confusion would be a bug
and shouldn't happen, and it hasn't happened in ~16 hours of testing
with the Linux kernel list, but you never know.)

In addition, j now generates the appropriate "References" header when
you reply to a message, which is needed to support sorting by thread
on the receiving end.

I've also fixed a few minor bugs introduced in the last couple of
snapshots.

Thanks for your support.

-Peter

[j-devel] Two important IMAP improvements

[Peter G. <pe...@ar...>]

This morning's 0.16.1+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot introduces two big improvements in the handling of IMAP
mailboxes.

First, this snapshot fixes j's handling of new vs.old messages in IMAP
mailboxes, which has always been a little broken but was very broken
in yesterday's snapshot.

Even with yesterday's snapshot, nothing disastrous happened, but
messages tended to show up in mailboxes for the first time as 'O'
(old) rather than 'N' (new).

Part of the problem is that the IMAP server is not guaranteed to copy
the flags with the message when the message is moved from one folder
to another. To quote from RFC 2060:

    The flags and internal date of the message(s) SHOULD be preserved
    in the copy.

"SHOULD", not "MUST".

Which means that messages processed by incoming filters may lose the
"recent" flag.

Before yesterday, j's approach to this was to set the recent flag on
all messages when they (or their header information) arrived on the
client machine. This approach worked fine most of the time, but if you
lost your cached headers and j had to re-fetch them, all the messages
in the mailbox in question would show up as 'N', which was not a good
thing. Losing your cached headers was relatively rare but did occur
from time to time, for example if the header cache changed its
serialization, and should in any case be a completely benign event.

Starting with this morning's snapshot, j tries to be a bit smarter
about this issue. If you're fetching the whole mailbox, j now leaves
the recent flag alone, which means you'll get whatever the server
sends down. If, on the other hand, j is working from a valid header
cache, which is the normal case, messages that have shown up since the
cache was last saved or since you last invoked mailboxGetNewMessages
(Shift G in mailbox mode), whichever is later, will get the 'N' flag.
(The automatic check mail task, if you have it turned on, will not
change any 'N' flags to 'O', and any messages it retrieves will have
the'N' flag set.)

Bottom line, all of this now seems to work the way I think I expect it
to... ;)

Second, this snapshot introduces what seems to be a really huge
improvement in the way j checks for new mail.

In previous versions, j re-selected the folder when checking for new
mail, mostly in order to have a fresh value for UIDNEXT, in order to
be able to tell whether there was, in fact, any new mail. Re-selecting
the folder is an expensive operation that takes ~2-5 seconds on annie
(just for example). The mailbox was locked while that happened, which
meant you lost the use of the mailbox for that period of time.

Starting with this snapshot, j uses a much lighter-weight approach
when checking for new mail. Now we just do "UID FETCH n:*", where n is
the UID of the last message that we've already got. If there are any
new messages, this command suffices to get their header information.
If there are no new messages, the server sends header information
about the last message in the mailbox, which we already have and
consequently can ignore.

If there are no new messages, this whole process takes less than 30 ms
(with a fast connection), which is two orders of magnitude faster than
re-selecting the folder.

This approach still isn't exactly right, since it generates a little
more network traffic than is absolutely necessary, but it's a big
improvement and it will do for the moment.

The exactly right approach (short of using the optional IDLE
extension) is to poll with NOOP and use the server's untagged
responses to track changes in the mailbox, which would reduce the
network traffic in the no-new-messages case to 20 bytes or so. I'll be
moving the code in this direction in the near future.

Thanks for your support.

-Peter

Re: [j-devel] Saving over ssh

[Peter G. <pe...@ar...>]

> A while ago, I submitted a request for a "save via ssh" feature on =

> SourceForge. It appears that the request was accepted, and I was =

> wondering how development was coming and if I could help out in any way=
=2E =

> I'm a bit of a Java head, and though I haven't scrutinized the souce of=
 =

> J, I would be happy to help develop the SSH portion.

Save via ssh has been in the code for a long time (since February 2001
or so). It's one of j's hidden features... ;)

There's a description of how to set things up here:

    http://sourceforge.net/mailarchive/forum.php?thread_id=3D845730&forum=
_id=3D9737

So the first thing to do is try out the existing code to see if it
works for you.

The code, which is pretty much a pig's breakfast, is mainly in
Ssh.java and SshSession.java, but you should probably look at
SshFile.java too, and maybe RemoteBuffer.java.

The feature currently works only on Linux (it might work on other
flavors of Unix, but I don't think anyone has investigated that). It
needs jpty, to give you a controlling terminal; otherwise the password
prompt appears in the xterm from which you started j (among other
problems).

You should build jpty from source for your particular system, which
can be done by running ./configure with the --with-jpty option:

    ./configure --with-jdk=3D... --with-jpty
    make
    su
    make install

Or you can use Ant and add this line to build.properties:

    jpty=3Dyes

I know a couple of folks (one of them being me) who edit files via ssh
on a daily basis, and for the most part things do work correctly, at
least on Debian. Error handling leaves something to be desired,
however, and it would be nice to see if it works on other systems and
remove any Debian-centricities.

So it would be great if you could try it out and have a look at the
code.

Thanks for your help!

-Peter

[j-devel] Saving over ssh

[Dave S. <Dav...@by...>]

Peter and friends,

I love J. Thank you for making such a versatile editor. It's great to be 
able to run J on any platform and even though it's Java, it runs very 
quickly for me.

A while ago, I submitted a request for a "save via ssh" feature on 
SourceForge. It appears that the request was accepted, and I was 
wondering how development was coming and if I could help out in any way. 
I'm a bit of a Java head, and though I haven't scrutinized the souce of 
J, I would be happy to help develop the SSH portion.

Thanks.

--Dave

[j-devel] Sort by thread

[Peter G. <pe...@ar...>]

This morning's 0.16.1+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot introduces sorting by thread in mailboxes of all sorts.

In mailbox mode, there are two new items on the View menu, "Sort by
Date Sent" and "Sort by Thread", which do what their names suggest. If
you don't like menus, there are also two new commands, sortByDateSent
and sortByThread, which do the same thing.

Sort by thread should work in all mailboxes. I've tested it extensively
with IMAP and local mbox-style mailboxes. I haven't tried POP, but POP
should inherit the new functionality since it uses an mbox-style
mailbox for storage.

J's threading is 100% accurate about 99% of the time (compared to
mutt, which, by definition, is 100% accurate 100% of the time). I'm
continuing to work on that last percent... ;) Bear in mind that sort
by thread is just a view; it doesn't actually modify the underlying
data in any way.

While working on sort by thread, I ended up rewriting large chunks
of the mail code to make it cleaner and more efficient. This
introduced a certain amount of breakage early on, but I think it's
fixed now.

There is a minor issue if you use incoming filters to move messages
from one IMAP folder to another. In previous versions, j arbitrarily
set the RECENT flag (i.e. 'N') on all messages received via IMAP, on
the theory that the message may not be new, but it's new to us. This
was clearly wrong, and I took it out in the current snapshot. But I
probably need to do something to set the RECENT flag for messages that
are RECENT to begin with and get moved to another folder; it only
makes sense that they should still be RECENT when they get to their
new folder, but in the current implementation that's not happening.

If sort by thread doesn't work for you right out of the box, you may
need to delete the cached IMAP summary files, which are in
~/.j/mail/imap, and the "catalog" file in the same directory. You can
keep the cached messages (everything in ~/.j/mail/imap/cache and
below). For local mailboxes, you might have to delete mbox.summary, if
it exists (assuming the local mailbox is named "mbox"). J will
recreate whatever summary files it needs.

Note that j doesn't even pretend to offer full support for local
mailboxes. The most you can do with a local mailbox is Alt X,
openMailbox, enter the name of the mailbox file (which must be in mbox
format), and you'll get what amounts to a read only view of the
mailbox in question. It may seem like you can delete messages, mark
them read, etc., but the changes don't stick. Use IMAP for real mail.

In the current snapshot, when a mailbox is first opened it is always
sorted by date sent, and manual intervention is required to get it
sorted by thread. It would be much nicer for j to remember and restore
the user's preference in this regard on a per-mailbox basis, but that
won't happen until per-mailbox properties are implemented.

I'm hoping to release 0.16.2 early this week with the current feature
set, more or less, after I clean up the mail code a bit more and fix
the two bugs in the SourceForge bug tracker, so please let me know if
you notice any other anomalies in the current snapshot.

Thanks for your support.

-Peter

[j-devel] Local caching for IMAP mail messages

[Peter G. <pe...@ar...>]

This morning's 0.16.1+ development snapshot is up:

    http://armedbear.org/j.zip          (source and documentation)
    http://armedbear.org/j-jar.zip      (just j.jar)

Now that I'm back from vacation, this snapshot introduces local
caching for IMAP mail messages, while the need for it is fresh in my
mind... ;)

You don't have to do anything special to take advantage of local
message caching. When you read a message in an IMAP mailbox, j now
saves a copy of it locally (as a file unto itself, in a directory
specific to the mailbox in question, under ~/.j/mail/imap/cache). If
you subsequently go back and read the same message again, j will get
it out of the cache instead of pulling the same bits over the network
again. Disk is cheap.

Deleted messages are automatically removed from the cache when you do
an expunge. The current implementation has no concept of expiration or
aging of undeleted messages and imposes no limit on utilization of
disk space.

There is also no way (at the moment) to tell j to go fetch a bunch of
unread messages and cache local copies of them (which would be a
really cool feature if it happened in a background thread with a
configurable bandwidth limit).

IMAP message caching can be disabled entirely by adding this line to
~/.j/prefs:

    imapUseLocalCache = false

imapUseLocalCache is true by default (slavishly emulating Evolution).

Thanks for your support.

-Peter