jEdit

Rev# 22181 addresses some of the issues that were raised.

Re: changing these values to an enum: that would break some code. And
Console uses the constant
values from GeneralOptionPane now to decide if it should to do its file
status checking after a system shell execute.

Re: not using bit flags - The reason I changed the actual values in the
first place was so I *could* use bitwise
operations! You say I shouldn't? You really like super long compound if
statements better?

1. Original cause of the bug, and the fix, is to move code out of
View.setBuffer() and into EditPane.setBuffer().
Because some plugins were setting the buffer that way and not getting a
file status check.

2. Why the change on mapping of checkFileStatus was required?
I wanted to simplify the options and remove reference to "buffer save" from
all options. Since I was
removing one of the options I decided to change the mapping to make things
a bit simpler for me.

3. Two public variants of View#setBuffer() were removed, and all the
internal calls were mapped to setBuffer(Buffer). Please explain how
can we assume these removal are safe. At least they should be
mentioned as API changes, I think.

That's in the changelog for trunk but not in the merge request. sorry.
I can't guarantee it is safe. You can justify rejecting this merge request
on that
reason alone, I suppose. I just don't think the methods are necessary and
would be very surprised if any plugins used them.

4. jedit_en.props was updated. It seems that the semantics of same label
were changed. Isn't it mean we need updates on other language props?
Yes.

5. Reason is that if it happens before loadCaretInfo, it seems to interfere
with the caret restoration.

6. do I need to use bitwise operations? No, but I thought it would make
things a bit more elegant.

I think perhaps this is more than bug fix and probably can not be merged
into a stable branch.

Here are some links for convenience.
http://sourceforge.net/support/tracker.php?aid=1871440
http://jedit.svn.sourceforge.net/jedit/?view=rev&rev=22111
http://jedit.svn.sourceforge.net/jedit/?view=rev&rev=22142

I had to set "-x --ignore-eol-style" to avoid a conflict on
jedit_en.props for r22111.

I attached a result of manual resolution for the conflict on CHANGES.txt.

Some conceptual questions arised. I read the log message and the
comments on the original bug #1871440. But I felt that I don't get idea
about the changes enough to justify them. Please give answers for these
questions.

- What was the actual cause of the bug #1871440?
Were some options just not implemented?

- Why the change on mapping of checkFileStatus was required?
Isn't it possible to keep the meaning and map new values for the new
behavior?

- Two public variants of View#setBuffer() were removed, and all the
internal calls were mapped to setBuffer(Buffer). Please explain how
can we assume these removal are safe. At least they should be
mentioned as API changes, I think.

- jedit_en.props was updated. It seems that the semantics of same label
were changed. Isn't it mean we need updates on other language props?

- There is a comment on the new code in EditPane.java.
> // This must happen after loadCaretInfo. Why?
> int check = jEdit.getIntegerProperty("checkFileStatus");
> if (jEdit.isStartupDone() && (check &
GeneralOptionPane.checkFileStatus_focusBuffer) > 0);
> jEdit.checkBufferStatus(view, true);
We should have answer for the "Why?" to justify the change.


Followings are some comments as a general code review.

In the above quoted code, the use of checkFileStatus_focusBuffer as a
bit flag seems like a dangerous coupling. Is it really necessary? What
do you think about, for example, having enum for checkFileStatus and
have a method like boolean onBufferFocus() ?

The comment on the jedit.props which says only "1=view focus" should
refer class GeneralOptionPane for complete definition.

Import of GeneralOptionPane from Buffer.java should be removed.

Rev#22142 adds a one-time migration step for fixing the value of
checkFileStatus property
whose value of 0's meaning is now 1.
Please merge 22142 as part of this request.