jedit-devel Mailing List for jEdit

Kazutoshi Satoda schrieb:
> Marcelo Vanzin wrote:
>   
>> On Wed, Apr 29, 2009 at 6:24 AM, Kazutoshi Satoda
>> <k_s...@f2...> wrote:
>>     
>>> I think "This is not a part of API" is a straightforward wording.
>>> Alan, could you please replace the wording of such public classes?
>>>
>>> While I think, as Dale said, it is not to good to distinguish API by
>>> documentation, it looks too hard to restructure the packages so that
>>> all such classes can be declared non-public.
>>>       
>> Why not just not include the non-API packages (or classes if you want
>> to go into that level of granularity) in the "public" javadoc? That
>> way it's easy: if it's documented in the javadocs provided with jEdit,
>> you can safely use it.
>>     
>
> +1 for excluding the non-API package or classes in API docs.
>
> However, I want the distinction to be clear and easy to find while
> working on the core. Placing the distinction in the comment for such
> classes (in *.java file) will be better for that.
>
> I think the consistent wording can be used to automatically exclude such
> classes from the resulted API docs. (Excuse me but I'm not sure that it
> can be done in an Ant task. I just know it is possible in theory.)
>
>   
I don't think so. For filtering it automated with the words, it must be 
EXACTLY spelled which is from my experience hard to enforce and 
addtionally you cannot just exclude or delete the already built JavaDoc 
pages, because e. g. then there would be dead links in the overview 
pages and indices. If you don't want to provide the docs for the non-API 
classes, then you have to exclude it from the doc-build-process already.

Plugin Feature Requests item #2761999, was opened at 2009-04-14 16:37
Message generated for change (Comment added) made by voituk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2761999&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Open
Priority: 5
Private: No
Submitted By: tuty sara (tutysara)
Assigned to: Voituk Vadim (voituk)
Summary: FTP : Autopopulation of username, password, server name

Initial Comment:
In the FTP plugin connection is established by selecting "FTP -> Open from FTP server..." or "FTP ->Open from secure FTP server..." option.
Most of the time we open a connection to the same server.
It would be better and faster if we auto populate these fields with the last entered values and select them so, that the user could enter new values or continue with the old values entered. 

----------------------------------------------------------------------

>Comment By: Voituk Vadim (voituk)
Date: 2009-04-30 23:49

Message:
Reopened.

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2009-04-30 05:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Kevin Hunter (hunteke)
Date: 2009-04-15 19:45

Message:
<blockquote>First, the old values are available by HistoryTextField, so you
can always
select them without re-typing your credentials.</blockquote>

Yes, that's true, but I have to select both.  When I open a file, and it
needs to ask (restarted jEdit, no currently open files, etc.), if I've
typed it in before, I believe the request is "Can the plugin auto-populate
the password field?"

<blockquote>Second, you don't even need to use that dialog to open up
another file
from the same place as your current file.</blockquote>

Right on.  But restart jEdit, and it asks afresh for a password.  Why? 
I'll bet this is a security issue because otherwise you'd need store the
password somewhere on the disk.  Is there some compromise that could be
made?  Like an "Are you *really* sure you want to do that?"  dialog.  In my
case, with a completely personal computer that I secure via other means,
the answer would be yes.

Similarly, if I use another form of "automatic" authentication, such as an
SSH key, having it cached or auto-populated, or even auto-tried, would be
nice.  I still have to manually select it.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2009-04-15 17:58

Message:
First, the old values are available by HistoryTextField, so you can always
select them without re-typing your credentials.

Second, you don't even need to use that dialog to open up another file
from the same place as your current file.
Just do "open file" and the regular file browser will show you other files
in the same directory, whether it is local or remote.


----------------------------------------------------------------------

Comment By: Voituk Vadim (voituk)
Date: 2009-04-15 13:11

Message:
In a current build the previous values are available from drop-down box.

But i like the idea to "Do not ask for already existing credentials on
file open" 

----------------------------------------------------------------------

Comment By: Voituk Vadim (voituk)
Date: 2009-04-15 13:11

Message:
In a current build the previous values are available from drop-down box.

But i like the idea to "Do not ask for already existing credentials on
file open" 

----------------------------------------------------------------------

Comment By: Kevin Hunter (hunteke)
Date: 2009-04-14 16:49

Message:
Or, at the risk of feature creep, maybe having a list of past saved values.
 Would be nice not to keep having to select my private key.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2761999&group_id=588

Matthieu Casanova wrote:
> 2009/4/30 Kazutoshi Satoda <k_s...@f2...>
>> If you know such a member, which is public (or protected) but not a part
>> of API in a API-class, could you please show us one (or more) example?
>>
>> I don't know such one, and can't imagine why fixing it causes hardness
>> like you said.
>>
> For example
> VFSManager.init()
> VFSManager.start()
> 
> and probably a lot more

Thanks. I found more 4 occurrences by searching "Do not call". I'll take
a look at these to see how hard to fix them.

If you know other methods or words to search, please let us know.

-- 
k_satoda

Thanks!  I'd forgotten about this too.  I have a suggestion, would you 
add a another SPAN_REGEX block for IS_SELECTED?

Thanks,

Dale


Matthieu Casanova wrote:
> Ih yes sorry (and Sorry Dale, you asked me and I forgot), it is in the 
> trunk now
>
> Matthieu
>
> 2009/4/30 Kazutoshi Satoda <k_s...@f2... 
> <mailto:k_s...@f2...>>
>
>     Hi Matthieu,
>
>     I got an error for missing jedit-actions.xml file when I opened the
>     actions.xml.
>
>     I found the following message on jedit-devel from Dale. I guess you
>     missed this message since you were not explicitly addressed in To: nor
>     CC: of the mail. Now I expect you could catch this.
>
>     Please add the file.
>
>
>     Dale Anson wrote:
>
>         I see you added a jedit-actions mode.  I noticed this because
>         I wanted one, so I wrote one, and saw your mode already in the
>         catalog file.  However, I don't find the corresponding
>         jedit-actions.xml file.  Would you check it in please?
>
>
>         kp...@us...
>         <mailto:kp...@us...> wrote:
>
>             Revision: 14646
>                    
>              http://jedit.svn.sourceforge.net/jedit/?rev=14646&view=rev
>             <http://jedit.svn.sourceforge.net/jedit/?rev=14646&view=rev>
>             Author:   kpouer
>             Date:     2009-02-12 15:00:51 +0000 (Thu, 12 Feb 2009)
>
>             Log Message:
>             -----------
>             added jedit-actions edit mode
>
>             Modified Paths:
>             --------------
>                jEdit/trunk/doc/CHANGES.txt
>                jEdit/trunk/modes/catalog
>                jEdit/trunk/org/gjt/sp/jedit/actions.xml
>                jEdit/trunk/org/gjt/sp/jedit/browser.actions.xml
>
>     (snip)
>
>     -- 
>     k_satoda
>
>

2009/4/30 Kazutoshi Satoda <k_s...@f2...>

> Matthieu Casanova wrote:
>
>> 2009/4/30 Marcelo Vanzin <va...@us...>
>>
>>> But I really don't like the idea of mixing public and non-public APIs
>>> in the same class.
>>>
>>
>> That's right, but not so easy, it would require to move a lot of classes
>> and
>> would be very complicated, and I'm sure we would have unexpected problems.
>> Of course some public modifiers could be changed but it would never be
>> perfect
>>
>
> If you know such a member, which is public (or protected) but not a part
> of API in a API-class, could you please show us one (or more) example?
>
> I don't know such one, and can't imagine why fixing it causes hardness
> like you said.
>
>
For example
VFSManager.init()
VFSManager.start()

and probably a lot more

Matthieu

Matthieu Casanova wrote:
> 2009/4/30 Marcelo Vanzin <va...@us...>
>> But I really don't like the idea of mixing public and non-public APIs
>> in the same class.
> 
> That's right, but not so easy, it would require to move a lot of classes and
> would be very complicated, and I'm sure we would have unexpected problems.
> Of course some public modifiers could be changed but it would never be
> perfect

If you know such a member, which is public (or protected) but not a part
of API in a API-class, could you please show us one (or more) example?

I don't know such one, and can't imagine why fixing it causes hardness
like you said.

-- 
k_satoda

Ih yes sorry (and Sorry Dale, you asked me and I forgot), it is in the trunk
now

Matthieu

2009/4/30 Kazutoshi Satoda <k_s...@f2...>

> Hi Matthieu,
>
> I got an error for missing jedit-actions.xml file when I opened the
> actions.xml.
>
> I found the following message on jedit-devel from Dale. I guess you
> missed this message since you were not explicitly addressed in To: nor
> CC: of the mail. Now I expect you could catch this.
>
> Please add the file.
>
> Dale Anson wrote:
>
>> I see you added a jedit-actions mode.  I noticed this because I wanted
>> one, so I wrote one, and saw your mode already in the catalog file.
>>  However, I don't find the corresponding jedit-actions.xml file.  Would you
>> check it in please?
>>
>
>  kp...@us... wrote:
>>
>>> Revision: 14646
>>>          http://jedit.svn.sourceforge.net/jedit/?rev=14646&view=rev
>>> Author:   kpouer
>>> Date:     2009-02-12 15:00:51 +0000 (Thu, 12 Feb 2009)
>>>
>>> Log Message:
>>> -----------
>>> added jedit-actions edit mode
>>>
>>> Modified Paths:
>>> --------------
>>>    jEdit/trunk/doc/CHANGES.txt
>>>    jEdit/trunk/modes/catalog
>>>    jEdit/trunk/org/gjt/sp/jedit/actions.xml
>>>    jEdit/trunk/org/gjt/sp/jedit/browser.actions.xml
>>>
>>>  (snip)
>
> --
> k_satoda
>

2009/4/30 Marcelo Vanzin <va...@us...>

> On Wed, Apr 29, 2009 at 3:22 PM, Matthieu Casanova
> <cho...@gm...> wrote:
> > But how do you force javadoc to remove the non api methods ? Some of them
> > may be "public" but not part of the api.
> > Maybe an annotation ?
>
> I'm assuming that we don't want to get into a situation where the same
> class has public methods which are "public API" and public methods
> which are not. I think that's bad design.
>
> My suggestion was to control "the public API" by packages; we have
> packages which we consider public and generate docs for, and packages
> which are not. If that is not deemed enough, we could do it at class
> granularity (also equals more maintenance related to the ant task that
> generates the docs).
>
> But I really don't like the idea of mixing public and non-public APIs
> in the same class.
>

That's right, but not so easy, it would require to move a lot of classes and
would be very complicated, and I'm sure we would have unexpected problems.
Of course some public modifiers could be changed but it would never be
perfect

Matthieu

Hi Matthieu,

I got an error for missing jedit-actions.xml file when I opened the
actions.xml.

I found the following message on jedit-devel from Dale. I guess you
missed this message since you were not explicitly addressed in To: nor
CC: of the mail. Now I expect you could catch this.

Please add the file.

Dale Anson wrote:
> I see you added a jedit-actions mode.  I noticed this because I wanted 
> one, so I wrote one, and saw your mode already in the catalog file.  
> However, I don't find the corresponding jedit-actions.xml file.  Would 
> you check it in please?

> kp...@us... wrote:
>> Revision: 14646
>>           http://jedit.svn.sourceforge.net/jedit/?rev=14646&view=rev
>> Author:   kpouer
>> Date:     2009-02-12 15:00:51 +0000 (Thu, 12 Feb 2009)
>>
>> Log Message:
>> -----------
>> added jedit-actions edit mode
>>
>> Modified Paths:
>> --------------
>>     jEdit/trunk/doc/CHANGES.txt
>>     jEdit/trunk/modes/catalog
>>     jEdit/trunk/org/gjt/sp/jedit/actions.xml
>>     jEdit/trunk/org/gjt/sp/jedit/browser.actions.xml
>>
(snip)

-- 
k_satoda

Plugin Feature Requests item #2761999, was opened at 2009-04-14 13:37
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2761999&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: tuty sara (tutysara)
Assigned to: Voituk Vadim (voituk)
Summary: FTP : Autopopulation of username, password, server name

Initial Comment:
In the FTP plugin connection is established by selecting "FTP -> Open from FTP server..." or "FTP ->Open from secure FTP server..." option.
Most of the time we open a connection to the same server.
It would be better and faster if we auto populate these fields with the last entered values and select them so, that the user could enter new values or continue with the old values entered. 

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2009-04-30 02:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Kevin Hunter (hunteke)
Date: 2009-04-15 16:45

Message:
<blockquote>First, the old values are available by HistoryTextField, so you
can always
select them without re-typing your credentials.</blockquote>

Yes, that's true, but I have to select both.  When I open a file, and it
needs to ask (restarted jEdit, no currently open files, etc.), if I've
typed it in before, I believe the request is "Can the plugin auto-populate
the password field?"

<blockquote>Second, you don't even need to use that dialog to open up
another file
from the same place as your current file.</blockquote>

Right on.  But restart jEdit, and it asks afresh for a password.  Why? 
I'll bet this is a security issue because otherwise you'd need store the
password somewhere on the disk.  Is there some compromise that could be
made?  Like an "Are you *really* sure you want to do that?"  dialog.  In my
case, with a completely personal computer that I secure via other means,
the answer would be yes.

Similarly, if I use another form of "automatic" authentication, such as an
SSH key, having it cached or auto-populated, or even auto-tried, would be
nice.  I still have to manually select it.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2009-04-15 14:58

Message:
First, the old values are available by HistoryTextField, so you can always
select them without re-typing your credentials.

Second, you don't even need to use that dialog to open up another file
from the same place as your current file.
Just do "open file" and the regular file browser will show you other files
in the same directory, whether it is local or remote.


----------------------------------------------------------------------

Comment By: Voituk Vadim (voituk)
Date: 2009-04-15 10:11

Message:
In a current build the previous values are available from drop-down box.

But i like the idea to "Do not ask for already existing credentials on
file open" 

----------------------------------------------------------------------

Comment By: Voituk Vadim (voituk)
Date: 2009-04-15 10:11

Message:
In a current build the previous values are available from drop-down box.

But i like the idea to "Do not ask for already existing credentials on
file open" 

----------------------------------------------------------------------

Comment By: Kevin Hunter (hunteke)
Date: 2009-04-14 13:49

Message:
Or, at the risk of feature creep, maybe having a list of past saved values.
 Would be nice not to keep having to select my private key.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2761999&group_id=588

Hi Matthieu,

Kazutoshi Satoda wrote:
> Unfortunately, we now live in class granularity. In jedit.buffer package,
> some public classes are API but some are documented "internal" and
> "should not use directly".
> http://www.jedit.org/api/org/gjt/sp/jedit/buffer/package-summary.html

Could you please take another look at the "public" declaration of such
classes?

I found that PositionManager and ContentManager doesn't need to be
public (does compile without "public"), but UndoManager needs it only
for Buffer which is in jedit package. It might be solved with
reasonable work.

-- 
k_satoda

Marcelo Vanzin wrote:
> On Wed, Apr 29, 2009 at 3:22 PM, Matthieu Casanova
> <cho...@gm...> wrote:
>> But how do you force javadoc to remove the non api methods ? Some of them
>> may be "public" but not part of the api.
>> Maybe an annotation ?
> 
> I'm assuming that we don't want to get into a situation where the same
> class has public methods which are "public API" and public methods
> which are not. I think that's bad design.

That's right. My last definition already excluded such methods. I think
they can be easily fixed if it is now wrongly declared as public or
protected.

> My suggestion was to control "the public API" by packages; we have
> packages which we consider public and generate docs for, and packages
> which are not. If that is not deemed enough, we could do it at class
> granularity (also equals more maintenance related to the ant task that
> generates the docs).

Unfortunately, we now live in class granularity. In jedit.buffer package,
some public classes are API but some are documented "internal" and
"should not use directly".
http://www.jedit.org/api/org/gjt/sp/jedit/buffer/package-summary.html

-- 
k_satoda

Marcelo Vanzin wrote:
> On Wed, Apr 29, 2009 at 6:24 AM, Kazutoshi Satoda
> <k_s...@f2...> wrote:
>> I think "This is not a part of API" is a straightforward wording.
>> Alan, could you please replace the wording of such public classes?
>>
>> While I think, as Dale said, it is not to good to distinguish API by
>> documentation, it looks too hard to restructure the packages so that
>> all such classes can be declared non-public.
> 
> Why not just not include the non-API packages (or classes if you want
> to go into that level of granularity) in the "public" javadoc? That
> way it's easy: if it's documented in the javadocs provided with jEdit,
> you can safely use it.

+1 for excluding the non-API package or classes in API docs.

However, I want the distinction to be clear and easy to find while
working on the core. Placing the distinction in the comment for such
classes (in *.java file) will be better for that.

I think the consistent wording can be used to automatically exclude such
classes from the resulted API docs. (Excuse me but I'm not sure that it
can be done in an Ant task. I just know it is possible in theory.)

-- 
k_satoda

On Wed, Apr 29, 2009 at 3:22 PM, Matthieu Casanova
<cho...@gm...> wrote:
> But how do you force javadoc to remove the non api methods ? Some of them
> may be "public" but not part of the api.
> Maybe an annotation ?

I'm assuming that we don't want to get into a situation where the same
class has public methods which are "public API" and public methods
which are not. I think that's bad design.

My suggestion was to control "the public API" by packages; we have
packages which we consider public and generate docs for, and packages
which are not. If that is not deemed enough, we could do it at class
granularity (also equals more maintenance related to the ant task that
generates the docs).

But I really don't like the idea of mixing public and non-public APIs
in the same class.

-- 
Marcelo Vanzin
mmv...@gm...
"Life's too short to drink cheap beer."

But how do you force javadoc to remove the non api methods ? Some of them
may be "public" but not part of the api.
Maybe an annotation ?

Matthieu

2009/4/29 Marcelo Vanzin <va...@us...>

> On Wed, Apr 29, 2009 at 6:24 AM, Kazutoshi Satoda
> <k_s...@f2...> wrote:
> > I think "This is not a part of API" is a straightforward wording.
> > Alan, could you please replace the wording of such public classes?
> >
> > While I think, as Dale said, it is not to good to distinguish API by
> > documentation, it looks too hard to restructure the packages so that
> > all such classes can be declared non-public.
>
> Why not just not include the non-API packages (or classes if you want
> to go into that level of granularity) in the "public" javadoc? That
> way it's easy: if it's documented in the javadocs provided with jEdit,
> you can safely use it.
>
> We can have an ant target to generate all docs (including non-public
> APIs) if developers feel they need it.
>
> This is what Sun does, and you don't see people using all the sun.*
> classes which are available in the JRE in their programs. If you do,
> you're on your own.
>
> This is much easier than refactoring everything so that you have
> proper public / protected / private classes, which in some cases is
> not even possible unless you want all your code to live in the same
> package, which can become a mess very easily.
>
>
> --
> Marcelo Vanzin
> mmv...@gm...
> "Life's too short to drink cheap beer."
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

On Wed, Apr 29, 2009 at 6:24 AM, Kazutoshi Satoda
<k_s...@f2...> wrote:
> I think "This is not a part of API" is a straightforward wording.
> Alan, could you please replace the wording of such public classes?
>
> While I think, as Dale said, it is not to good to distinguish API by
> documentation, it looks too hard to restructure the packages so that
> all such classes can be declared non-public.

Why not just not include the non-API packages (or classes if you want
to go into that level of granularity) in the "public" javadoc? That
way it's easy: if it's documented in the javadocs provided with jEdit,
you can safely use it.

We can have an ant target to generate all docs (including non-public
APIs) if developers feel they need it.

This is what Sun does, and you don't see people using all the sun.*
classes which are available in the JRE in their programs. If you do,
you're on your own.

This is much easier than refactoring everything so that you have
proper public / protected / private classes, which in some cases is
not even possible unless you want all your code to live in the same
package, which can become a mess very easily.


-- 
Marcelo Vanzin
mmv...@gm...
"Life's too short to drink cheap beer."

On 29-Apr-09, at 12:10 PM, Kazutoshi Satoda wrote:
> In general, good subject should be enough to ignore the mail. Also,
> good organization of paragraphs will help lazy readers.
> http://www.useit.com/alertbox/reading_pattern.html


Interesting article, and certainly true of my reading patterns for  
mailing list messages. If I can't tell whether the message applies to  
me or is of interest to me from either the subject line or the first  
paragraph or two, I'm probably gonna trash it and move on.

Steve Jakob

Shlomy Reinstein wrote:
> Well, I accept your arguments.

Thank you.

> So maybe we need some way to formalize
> subject lines, so that developers who are not interested in such
> emails can ignore them.
> For example: [type-of-post] [component] real subject
(snip)
> Is that okay in general? Potentially, this will allow developers to
> write email filters so they don't have to spent time on posts that do
> not interest them.

Personally, I don't want such rule. It will be boring to put redundant
information by hands for every post, and also hard to guess what is the
correct and useful labeling. I guess others also won't (or can't) follow
such rule.

In general, good subject should be enough to ignore the mail. Also,
good organization of paragraphs will help lazy readers.
http://www.useit.com/alertbox/reading_pattern.html

As Dale suggested, so many "devel" mailing lists for other softwares
lives with much more volume. Some lists has a manner like you suggested.
But they are not a rule to be caught by filters. They only helps to make
the subject clearer. I think jedit-devel doesn't have any special reason
to make more rules.

-- 
k_satoda

I agree with Dale. I also like being able to search my gmail for keywords,
and on development lists, most of the hits are quite relevant.


On Wed, Apr 29, 2009 at 7:00 AM, Steve Jakob <ste...@wi...>wrote:

>
> On 29-Apr-09, at 9:31 AM, Dale Anson wrote:
> > I also prefer that discussions happen on the list rather than in
> > private.  Sometimes the discussions do go outside of the area of my
> > immediate interest (such as the current long thread about buffersets),
> > but it is good to know the discussion is going on and by having the
> > discussions on the list, they are available for others to read.
> >
> > Personally, I subscribe to several lists.  The jEdit lists (both user
> > and devel) are fairly low volume, so I read them just about every day.
> > Others, such as the PMD and Ant lists, are considerably higher volume,
> > and I tend to just skim them once a week or so.  Regardless, the
> > information is there should I need it, which I think is one of the
> > great
> > features of such lists.
>
> My feelings exactly.
>
> Steve Jakob
>
>
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Well, I accept your arguments. So maybe we need some way to formalize
subject lines, so that developers who are not interested in such
emails can ignore them.
For example: [type-of-post] [component] real subject
where:
[type-of-post] can be 'design', 'implementation', 'bug-fix', 'feature
request' etc.
[component] can be 'buffer sets', 'options', 'syntax highlighting',
'docking framework' etc.

Is that okay in general? Potentially, this will allow developers to
write email filters so they don't have to spent time on posts that do
not interest them.

Shlomy

On Wed, Apr 29, 2009 at 3:09 PM, Kazutoshi Satoda
<k_s...@f2...> wrote:
> Shlomy Reinstein wrote:
>> I think there should be a reasonable value to posting to the list. If
>> you think there is, please continue posting to this list.
>
> I already find the general value of posting to the list in this article.
> http://producingoss.com/en/setting-tone.html#avoid-private-discussions
>
>> I think that
>> getting to actual code lines wrt a specific feature / issue, should
>> not be discussed on the list. Keep in mind that anyone who is
>> subscribed to the list will have to spend a minimal bit of time on it,
>> even to find that it's not of his/her interest, and delete it or
>> whatever. Having a dozen or so messages a day just keeps accumulating.
>
> I think subscribing to the list means the subscriber are willing to
> spend such time. The subscription is up to the individual.
>
> Since jedit-devel is advertised as "A list where jEdit development
> issues are discussed" on the subscription page, all issues about
> development are OK to post, at least for now.
> http://lists.sourceforge.net/mailman/listinfo/jedit-devel
>
> If it is really unreasonably time consuming, then I think the problem
> is in the granularity of the lists. I think separating the tracker
> notification (to jedit-tracker?) might be good.
>
>> As a guideline, I would say: If it's something that is generic enough
>> to interest several developers (not just two or three), or it's about
>> the design of jEdit, or you want to ask how to implement a specific
>> thing when you don't know who can answer, then please post to the
>> list. When the post is very specific, and refers to actual code lines,
>> and you already know the involved people, do not post to the list but
>> rather to those involved. This is my opinion, at least.
>
> I can't accept this guideline.
>
> It seems to exclude potential contributors who might usually only read
> the list, and prevent public codereviews. Both are important for OSS in
> general, and very wanted for jEdit now.
>
> Also, the boundary seems to depend on too many things. A same topic can
> cross over the boundary while the discussion goes. This will make the
> archive incomplete, and hard to search or track later.
>
> --
> k_satoda
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

On 29-Apr-09, at 9:31 AM, Dale Anson wrote:
> I also prefer that discussions happen on the list rather than in
> private.  Sometimes the discussions do go outside of the area of my
> immediate interest (such as the current long thread about buffersets),
> but it is good to know the discussion is going on and by having the
> discussions on the list, they are available for others to read.
>
> Personally, I subscribe to several lists.  The jEdit lists (both user
> and devel) are fairly low volume, so I read them just about every day.
> Others, such as the PMD and Ant lists, are considerably higher volume,
> and I tend to just skim them once a week or so.  Regardless, the
> information is there should I need it, which I think is one of the  
> great
> features of such lists.

My feelings exactly.

Steve Jakob

Plugin Feature Requests item #2757830, was opened at 2009-04-13 08:50
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2757830&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: Immediately report errors to ErrorList

Initial Comment:
Currently, when running a process in the System shell of the Console, the error patterns only show up in the ErrorList plugin when the process completes. It would be very useful to show the errors in ErrorList immediately when they are captured by Console. E.g. a large build can create many errors, and it would be very useful if I could jump to them immediately as I see them and start working on them before the build process has completed.

----------------------------------------------------------------------

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-04-29 16:57

Message:
Submitted patch #2783642 for this. If you think an option is required, to
let the user decide about immediate / delayed reporting of errors, let me
know and I'll add it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2757830&group_id=588

Plugin Patches item #2783642, was opened at 2009-04-29 16:56
Message generated for change (Tracker Item Submitted) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2783642&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: Immediately report errors to ErrorList

Initial Comment:
A patch for feature request 2757830 (by myself). When a long process (e.g. project build) is executed, report errors to ErrorList immediately rather than waiting until the process ends. This enables me to start using ErrorList to work on the errors during the process.

If you think this requires another option in the Console plugin, to decide between immediate reporting and delayed reporting (like until now) let me know.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2783642&group_id=588

I also prefer that discussions happen on the list rather than in 
private.  Sometimes the discussions do go outside of the area of my 
immediate interest (such as the current long thread about buffersets), 
but it is good to know the discussion is going on and by having the 
discussions on the list, they are available for others to read. 

Personally, I subscribe to several lists.  The jEdit lists (both user 
and devel) are fairly low volume, so I read them just about every day.  
Others, such as the PMD and Ant lists, are considerably higher volume, 
and I tend to just skim them once a week or so.  Regardless, the 
information is there should I need it, which I think is one of the great 
features of such lists.

Dale


Kazutoshi Satoda wrote:
> Shlomy Reinstein wrote:
>   
>> I think there should be a reasonable value to posting to the list. If
>> you think there is, please continue posting to this list.
>>     
>
> I already find the general value of posting to the list in this article.
> http://producingoss.com/en/setting-tone.html#avoid-private-discussions
>
>   
>> I think that
>> getting to actual code lines wrt a specific feature / issue, should
>> not be discussed on the list. Keep in mind that anyone who is
>> subscribed to the list will have to spend a minimal bit of time on it,
>> even to find that it's not of his/her interest, and delete it or
>> whatever. Having a dozen or so messages a day just keeps accumulating.
>>     
>
> I think subscribing to the list means the subscriber are willing to
> spend such time. The subscription is up to the individual.
>
> Since jedit-devel is advertised as "A list where jEdit development
> issues are discussed" on the subscription page, all issues about
> development are OK to post, at least for now.
> http://lists.sourceforge.net/mailman/listinfo/jedit-devel
>
> If it is really unreasonably time consuming, then I think the problem
> is in the granularity of the lists. I think separating the tracker
> notification (to jedit-tracker?) might be good.
>
>   
>> As a guideline, I would say: If it's something that is generic enough
>> to interest several developers (not just two or three), or it's about
>> the design of jEdit, or you want to ask how to implement a specific
>> thing when you don't know who can answer, then please post to the
>> list. When the post is very specific, and refers to actual code lines,
>> and you already know the involved people, do not post to the list but
>> rather to those involved. This is my opinion, at least.
>>     
>
> I can't accept this guideline.
>
> It seems to exclude potential contributors who might usually only read
> the list, and prevent public codereviews. Both are important for OSS in
> general, and very wanted for jEdit now.
>
> Also, the boundary seems to depend on too many things. A same topic can
> cross over the boundary while the discussion goes. This will make the
> archive incomplete, and hard to search or track later.
>
>   

Alan Ezust wrote:
> Yeah, a consistent way of marking non-API classes would be nice. I'm sure
> that some are marked "not meant for public use" and others are marked "not
> use directly".
> 
> API is indeed the right acronym and should appear in each comment that
> indicates it is not part of the API, I think to help with consistency and
> skipping them during the doc generation process.

I think "This is not a part of API" is a straightforward wording.
Alan, could you please replace the wording of such public classes?

While I think, as Dale said, it is not to good to distinguish API by
documentation, it looks too hard to restructure the packages so that
all such classes can be declared non-public.

So, assuming we got consistent wordings for non-API, I propose the
following definition for API. Now it has words for protected, too.

  - A package is an API-package if it is not documented as non-API.
    Note that "documented as non-API" means the following sentence is
    included in its javadoc; "This is not a part of API".
  - A class is an API-class if it is declared public in an API-package
    and not documented as non-API, or declared public or protected in
    an API-class.
  - A non-class member of a class is an API-member if it is declared
    public or protected in an API-class.
  - the API is consist of API-packages, API-classes in them, and
    API-members in them.

If no one objects, I want the original discussion about compatibility
starts with this definition of API.
-- 
k_satoda