jedit-devel Mailing List for jEdit

Hello, jEdit-developers!

[Edit]-[Paste Previous] action doesn't seems to work under Win2000, JDK 1.3, jEdit 2.5pre4
There is Log file after using [Paste Previous] menu item:

[message] Log: java.version=1.3.0
[message] Log: java.vendor=Sun Microsystems Inc.
[message] Log: java.compiler=null
[message] Log: os.name=Windows 2000
[message] Log: os.version=5.0
[message] Log: os.arch=x86
[message] Log: user.home=C:\Documents and Settings\VKondakoff.VKONDAKOFF
 Exception occurred during event dispatching:
 java.lang.ClassCastException: javax.swing.DefaultListCellRenderer$UIResource
       at javax.swing.text.html.EditableView.setParent(Unknown Source)
       at javax.swing.text.CompositeView.replace(Unknown Source)
       at javax.swing.text.CompositeView.loadChildren(Unknown Source)
       at javax.swing.text.CompositeView.setParent(Unknown Source)
       at javax.swing.text.FlowView.loadChildren(Unknown Source)
       at javax.swing.text.CompositeView.setParent(Unknown Source)
       at javax.swing.text.html.ParagraphView.setParent(Unknown Source)
       at javax.swing.text.CompositeView.replace(Unknown Source)
       at javax.swing.text.BoxView.replace(Unknown Source)
       at javax.swing.text.CompositeView.loadChildren(Unknown Source)
       at javax.swing.text.CompositeView.setParent(Unknown Source)
       at javax.swing.text.html.BlockView.setParent(Unknown Source)
       at javax.swing.text.CompositeView.replace(Unknown Source)
       at javax.swing.text.BoxView.replace(Unknown Source)
       at javax.swing.text.CompositeView.loadChildren(Unknown Source)
       at javax.swing.text.CompositeView.setParent(Unknown Source)
       at javax.swing.text.html.BlockView.setParent(Unknown Source)
       at javax.swing.plaf.basic.BasicHTML$Renderer.<init>(Unknown Source)
       at javax.swing.plaf.basic.BasicHTML.createHTMLView(Unknown Source)
       at javax.swing.plaf.basic.BasicHTML.updateRenderer(Unknown Source)
       at javax.swing.plaf.basic.BasicLabelUI.propertyChange(Unknown Source)
       at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(Unknown Source)
       at javax.swing.JComponent.firePropertyChange(Unknown Source)
       at javax.swing.DefaultListCellRenderer.firePropertyChange(Unknown Source)
       at javax.swing.JLabel.setText(Unknown Source)
       at javax.swing.DefaultListCellRenderer.getListCellRendererComponent(Unknown Source)
       at javax.swing.plaf.basic.BasicListUI.updateLayoutState(Unknown Source)
       at javax.swing.plaf.basic.BasicListUI.maybeUpdateLayoutState(Unknown Source)
       at javax.swing.plaf.basic.BasicListUI.getPreferredSize(Unknown Source)
       at javax.swing.JComponent.getPreferredSize(Unknown Source)
       at javax.swing.JList.getPreferredScrollableViewportSize(Unknown Source)
       at javax.swing.ViewportLayout.preferredLayoutSize(Unknown Source)
       at java.awt.Container.preferredSize(Unknown Source)
       at java.awt.Container.getPreferredSize(Unknown Source)
       at javax.swing.JComponent.getPreferredSize(Unknown Source)
       at javax.swing.ScrollPaneLayout.preferredLayoutSize(Unknown Source)
       at java.awt.Container.preferredSize(Unknown Source)
       at java.awt.Container.getPreferredSize(Unknown Source)
       at javax.swing.JComponent.getPreferredSize(Unknown Source)
       at org.gjt.sp.jedit.gui.PastePrevious.<init>(PastePrevious.java:63)
       at org.gjt.sp.jedit.actions.paste_previous.actionPerformed(paste_previous.java:35)
       at org.gjt.sp.jedit.gui.InputHandler.executeAction(InputHandler.java:204)
       at org.gjt.sp.jedit.EditAction$Wrapper.actionPerformed(EditAction.java:238)
       at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
       at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)
       at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
       at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
       at javax.swing.AbstractButton.doClick(Unknown Source)
       at javax.swing.plaf.basic.BasicMenuItemUI$MouseInputHandler.mouseReleased(Unknown Source)
       at java.awt.Component.processMouseEvent(Unknown Source)
       at java.awt.Component.processEvent(Unknown Source)
       at java.awt.Container.processEvent(Unknown Source)
       at java.awt.Component.dispatchEventImpl(Unknown Source)
       at java.awt.Container.dispatchEventImpl(Unknown Source)
       at java.awt.Component.dispatchEvent(Unknown Source)
       at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
       at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
       at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
       at java.awt.Container.dispatchEventImpl(Unknown Source)
       at java.awt.Window.dispatchEventImpl(Unknown Source)
       at java.awt.Component.dispatchEvent(Unknown Source)
       at java.awt.EventQueue.dispatchEvent(Unknown Source)
       at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
       at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
       at java.awt.EventDispatchThread.run(Unknown Source)


BTW: I can't reproduce this bug using Win'98, JDK 1.3,  jEdit 2.5pre4

  

-- 
Best regards,
 Valery Kondakoff                  mailto:st...@or...
http://www.nbk.orc.ru -- Moscow Rock-Club "Nе Бей Копытом" Homepage
http://www.nbk.orc.ru/mtb -- MTB riding in Moscow

Hogan Long wrote:
> It might be a bitch to implement and thus not worth it.

Yes, it would require that caret positions are stored as line/offset
pairs. Right now, they are stored as an offset from the beginning of
the document. I guess making them line/offset pairs would be something
to consider when writing the new document model.

Slava

sa...@cb... wrote:
> 
> Hi,
> 
> Why buffer settingns hasn't file encoding property? It's useful for working
> with files with different file encoding at the same time.
> 
> One of possible solutions I think is to ask the question when user changes
> buffer encoding property:
> "Could you re-read file with new file encoding?"
> Answer "yes" means that file was read with incorrect file encoding. Answer
> "no"  means that user only wants to change current file encoding.

No, this is not a good idea. Because jEdit has no way to auto-detect the
encoding when loading a file, you will still need to go to the 'Global
Options' dialog box when loading a buffer. Its best to leave the setting
as global until we find a way to automatically detect a file's encoding
when it is being loaded.

Slava

na...@rv... wrote:
> 
> Plugin manager is not working for me in Jedit 2.5pre4.  None of the
> plugins that Mike has announced to be updated show up when I
> choose the update plugins option.

I have managed to reproduce this bug as well. I will try to fix it in the
next release.

Slava

Hi,

Why buffer settingns hasn't file encoding property? It's useful for working
with files with different file encoding at the same time. 

One of possible solutions I think is to ask the question when user changes
buffer encoding property:
"Could you re-read file with new file encoding?" 
Answer "yes" means that file was read with incorrect file encoding. Answer
"no"  means that user only wants to change current file encoding.

Andrey

> ----------
> От: 	mike dillon[SMTP:md...@st...]
> Ответ: 	jed...@li...
> Отправлено: 	31 мая 2000 г. 2:24
> On Tue, 30 May 2000 sa...@cb... wrote:
> > I can't get different lists of buffers in different views. They are
> > always the same. When I open the new file in one view it also appears
> > in another view. Is it a bug?
> 
> this is not a bug.
> -md
> 
	But it's very uncomfortable for working with large number of
different files. 

Andrey.

I don't know if this is documented, but if a line is very long, 200+
characters, the scroll bar across the bottom does not move all the way
over to the end of the line.  There is a point where you drag the bar to
the rightmost point and expect the line to end, but there are still
characters to scroll to manually (by using right arrow key).

Michael

Plugin manager is not working for me in Jedit 2.5pre4.  None of the 
plugins that Mike has announced to be updated show up when I 
choose the update plugins option.
---------------------------------------------------------
"Clothes make the man, naked people have little or no 
influence on society" --Mark Twain--

Nathan Tenney
Computer Specialist
K-SAR Video Productions
Utah State University
na...@rv...

On Tue, 30 May 2000 sa...@cb... wrote:
> I can't get different lists of buffers in different views. They are
> always the same. When I open the new file in one view it also appears
> in another view. Is it a bug?

this is not a bug.
-md

Hi.

> The text component in jEdit 2.4 and above is no longer modular. The last
> release that can be 'dropped in' to another application was jEdit 2.3.
> You could still hack the 2.4 text component to function outside of jEdit,
> but it will be a lot of work.

Guess I'll have to stick to the old version then. That's really not a big
problem, but I thought that I'do go along with the progress and include the
new, improved text area eventhough it wouldn't be much of a benefit to me. I
could use more token types, though, but I can proabobly hack that up myself.

> > P.S. Btw, is there any way to change the .h files to default to C++
syntax highlighting? I can't seem to figure it out.
>
> Yes, change the filename globs for the C and C++ modes.

Okay, thanks for the info.

Matt

I can't get different lists of buffers in different views. They are always
the same. When I open the new file in one view it also appears in another
view. Is it a bug?

At 02:43 AM 5/30/00, you wrote:
>Hogan Long wrote:
> > The fantastically wonderful supper terrific best features ever:
> > The column select and paste.  (Get the feeling I like this feature?)
> > This is really complicated but I will describe it here - I don't know if it
> > is even possible to implement in jEdit.   Here is how it worked:
> > In Brief you could select in one of 3 modes, by line, by "mark" (this
> > is the standard behavior), and by column.  When you selected by
> > column the selection would be a rectangular area on the screen.
>
>Umm... jEdit has rectangular selection. Try control-dragging. Read the
>docs to find out more.

DOH!  RTFM - sorry.  I tried it out and the delete is nice (even already used it)
but the paste is a little funky.
If I get a chance I will look at the code - maybe I can send you a fix.

> > Another nice thing about brief is that it would "float" the cursor
> > on white space or after the end of a line.
> > The cursor would change shape to let you know.  This was nice
> > because you could format stuff with more ease.
>
>I'm not sure I want to implement this. Most times when I click past
>the end of a line, I expect the cursor to be positioned on the last
>character. It would be annoying to have to 'aim' the mouse precisely
>every time.
>
>Slava

Yes well this is one of those user preferences things - I like to float - others
may not (it might have to do with growing up in the 60s :) )

Actually this feature is more important when you are moving around with the 
cursor keys - for example it makes lining up braces and such much easier.
I can see where a mouser would prefer the end of line.

It might be a bitch to implement and thus not worth it.


>-- 
>-----------------------------------------------
>jEdit Developers' List
>jEd...@li...
>http://lists.sourceforge.net/mailman/listinfo/jedit-devel

Hogan Long wrote:
> The fantastically wonderful supper terrific best features ever:
> The column select and paste.  (Get the feeling I like this feature?)
> This is really complicated but I will describe it here - I don't know if it
> is even possible to implement in jEdit.   Here is how it worked:
> In Brief you could select in one of 3 modes, by line, by "mark" (this
> is the standard behavior), and by column.  When you selected by
> column the selection would be a rectangular area on the screen.

Umm... jEdit has rectangular selection. Try control-dragging. Read the
docs to find out more.

> Another nice thing about brief is that it would "float" the cursor
> on white space or after the end of a line.
> The cursor would change shape to let you know.  This was nice
> because you could format stuff with more ease.

I'm not sure I want to implement this. Most times when I click past
the end of a line, I expect the cursor to be positioned on the last
character. It would be annoying to have to 'aim' the mouse precisely
every time.

Slava

Hi,

The text component in jEdit 2.4 and above is no longer modular. The last
release that can be 'dropped in' to another application was jEdit 2.3.
You could still hack the 2.4 text component to function outside of jEdit,
but it will be a lot of work.

> P.S. Btw, is there any way to change the .h files to default to C++ syntax highlighting? I can't seem to figure it out.

Yes, change the filename globs for the C and C++ modes.

Slava

On Mon, 29 May 2000, Matthew Kuperus Heun wrote:
> Are the other pieces (org.gjt.sp.util, FtpClient, regex, etc.) under 
> CVS somewhere?  I would like to be able to pull the latest versions 
> and rebuild jEdit locally, whenever necessary.

<snip>

> P.P.S.  I also know that FtpClient is in the gjt repository, but it's 
> not up to date with the version being used by jEdit.

OK, the other stuff is almost all on the CVS and should be up to date. as
far as i can tell, the com.microstar.xml package is still not on the CVS.
the modules required to build jEdit that are avilable via GJT CVS are as
follows:

gjt/org/sp/jedit
gjt/org/sp/util
gjt/gnu/regexp
gjt/com/fooware/net

the latest version of the FTPClient package used to be available from
http://fooware.com/, but it seems like that domain has been taken over by
Blockstackers (the Slashdot crew's commercial venture). oops. that was
weird. now i'm seeing the normal fooware.com site. what the fuck!

anyways, you can get the latest version of the FTP stuff from
http://www.fooware.com:9090/java.html.

bugger.

-md

Greetings:

There are a few pieces of the jEdit source that are not in the 
org.gjt.sp.jedit package.  I can see that org.gjt.sp.jedit is under 
CVS at gjt.

Are the other pieces (org.gjt.sp.util, FtpClient, regex, etc.) under 
CVS somewhere?  I would like to be able to pull the latest versions 
and rebuild jEdit locally, whenever necessary.

Cheers,

Matt


P.S.  I know that I can get the code from the distributed versions, 
and that's what I've been doing for a while.  But, I'd like to make 
it simpler by pulling it from a repository and re-building.

P.P.S.  I also know that FtpClient is in the gjt repository, but it's 
not up to date with the version being used by jEdit.

At 01:59 AM 5/27/00, you wrote:
>Hello everybody,
>
>jEdit in the CVS now does this; I added a few methods to InputHandler
>(getLastActionCount(), getLastAction()) and tweaked the home/end
>actions. Check it out.
>{clip}

Wow Slava you rock!  That is amazing - two hours between suggestion and
implementation!

I am flattered that you took my suggestion, and pleased that you knew a 
good interface when you saw one.

So... I'm going to be a pain and tell you about 2 other things that
the original DOS brief did better than editors do now.  Interesting historical
note: Brief was purchased by Borland and integrated into their development
environments - but over the years they have slowly removed the nice features
that the old Brief had - by now they are mostly all gone.

The fantastically wonderful supper terrific best features ever:
The column select and paste.  (Get the feeling I like this feature?)
This is really complicated but I will describe it here - I don't know if it
is even possible to implement in jEdit.   Here is how it worked:
In Brief you could select in one of 3 modes, by line, by "mark" (this
is the standard behavior), and by column.  When you selected by
column the selection would be a rectangular area on the screen.
(remember that Brief was a programmers' editor so it was always
mono-spaced like jEdit).  You could make this area wider by pressing
the right key or thinner by pressing the left key.  Similarly you could make
it taller by pressing down or shorter by pressing up.  I know it sounds
confusing but it is quite intuitive... you are selecting a set of columns
for a certain number of lines.  It is important to note that you could select
white space (i.e. the lower right corner could be at any location in the
row/column space even on a character that did not exist)
This seems confusing to me even as I am writing it - but this is the best
I can explain - so if you have questions ask - and maybe then I can clear
up any miss-understanding.
Ok once you selected your columns you could copy them (nothing changed
in the buffer, or cut/delete them.  If you cut/delete them the stuff to the
right of the column select moved to the left by column.  Here is an example

Now is the time for all
good men to come to
the aide of their country.

(you will need to look at the example in a mono-spaced editor like jEdit or
notepad to understand this example.)
Lets say I column select from the i in "is" to the e in "aide" and then hit
delete.
I would end up with

Now he time for all
good to come to
the  of their country

Similarly a paste operation moves stuff over by column.
Two important things about the paste.  First I would always
treat white-space like space characters... even if there was 
nothing on that line.  (an fill in spaces NOT TABS for you.)
Second it always left the cursor on the line below where the 
insert happened and just below the first character on the left.
This was REALLY useful when you wanted to insert by column
one lines worth.  You could prefix a whole list of stuff just by hitting
the insert button over and over - because you were in the perfect
place to insert the next thing - the current convention is to leave the
cursor after the last item on the right!  Then you have to back up
to the beginning.  I can give an example of this if people don't see
what I am talking about.
I think it is clear why this is a really useful feature for program
writing.
===============================================
Another nice thing about brief is that it would "float" the cursor
on white space or after the end of a line.
The cursor would change shape to let you know.  This was nice
because you could format stuff with more ease.
--------------------------------------------------------------------------------------------
I'm bringing these up as examples of really good program editor 
interface designs - they might not be good for jEdit - but I figured 
I should just toss them out there for discussion.

Thanks again for making the home/end keys work in the "best" way
Hogan

Hi.
Pure Java PHP Editor is getting more and more popular (eventhough I =
tried to keep things quiet until the first stable release there are some =
web directories that added it to their listings). It has had approx. =
1200 downloads since the first development version was released in late =
January.

Of course part of its, uh, success should be credited to jEdit as well - =
jEdit's text area is at the heart of the editor. But the version of the =
text area the editor uses is very old, obsolete even. Now that jEdit =
uses the cool XML-based modes I have the following questions:
- How hard would it be to port the new text area / XML mode system to =
Pure Java PHP Editor. With the old text area I just took =
org.gjt.sp.jedit.textarea and org.gjt.sp.jedit.syntax packages, included =
them in my application and everything worked fine. Has this changed?
- When does jEdit check for and load the modes? Is this part of one of =
the corresponding packages (mentioned above) or is it handled elsewhere?
- Are there any other source files text area and XML mode system depend =
on?

If somebody would be so kind as to answer this mail, he or she might =
find the following information useful:
- I wrote my own smart auto-identing code (although it's not all that =
good yet)
- I don't need all the modes - just NULL, HTML and PHP. Maybe XML too.

Thank you and keep up the good work.

Matt

P.S. Btw, is there any way to change the .h files to default to C++ =
syntax highlighting? I can't seem to figure it out.

na...@rv... wrote:
> 
> I have noticed that when I connect to my linux box using the ftp
> vfilesystem, that the file name for the symlinks include a -> and the
> path to the actual file that the symlink represents.  I don't know if it
> does this for every ftp server with symlinks, but I think this could be
> used to allow the ftp vfilesystem to follow symlinks....

Yeah, that is how symlinks are supposed to be handled in FTP. jEdit
just totally ignores them at the moment. In the next pre-release, I
will add proper symlink handling.

Slava

> jEdit in the CVS now does this; I added a few methods to InputHandler
> (getLastActionCount(), getLastAction()) and tweaked the home/end
> actions. Check it out.

This is great. Thanks, Slava.
Hogan's suggestion was the best thing to do.

-Dirk.

-- 
Sent through GMX FreeMail - http://www.gmx.net

Hello everybody,

jEdit in the CVS now does this; I added a few methods to InputHandler
(getLastActionCount(), getLastAction()) and tweaked the home/end
actions. Check it out.

Slava

Hogan Long wrote:
> I'm an old Brief user from way back (when it used to be owned
> by Underware Software - still love the pun even after 10 years)
> 
> They were, I believe, the first to implement the smart home -
> start of line - start of screen - start of document (and similar
> for end).  They were certainly the first to do it on the pc.
> 
> I still love that functionality - one of the things that they did that
> most imitators never figured out as being a "good" thing was the
> following:
> 
> The behavior of the smart end was based ONLY on the number
> of times you hit the key - not at all where you were on the line
> or on the screen.  Thus if you hit it once you will be at the end
> of the current line EVEN if you started there (almost no smart
> end does this currently!) if you hit it again you were at the end
> of the line on the last line on the screen EVEN if you started there
> etc.
> 
> This was very, very important functionality it allowed you to type
> and write macros (recorded macros) and not care about where you
> were on the line.  With current implementations there is no way to
> get to the end of the line and be sure of getting there unless I know
> where I currently am.  I don't like this.  But I do love the smart end in
> concept - and I think it would be a big feature to remove if it was taken
> out.

On Sat, 27 May 2000, Hogan Long wrote:
> The behavior of the smart end was based ONLY on the number
> of times you hit the key - not at all where you were on the line
> or on the screen.  Thus if you hit it once you will be at the end
> of the current line EVEN if you started there (almost no smart 
> end does this currently!) if you hit it again you were at the end
> of the line on the last line on the screen EVEN if you started there
> etc.

now that i think about it, this is exactly the reason why i don't use
jEdit's smart home/end. i can't stand that when i impulsively press
end at the end of the line, it would jump somewhere else. i think that
in addition to Hogan's explicit suggestion, it would be cool if the
home/end behavior actually cycled, so that i could keep pressing home
and eventually get back to the same line i started on. the memory for
home or end would be cleared as soon as another keypress occurred.

if this were implemented in addition to the first-whitespace/first-char/
screen-home behavior, i would probably actually use smart home/end
and be very happy with it.

At 11:27 PM 5/26/00, you wrote:
>Dirk Moebius wrote:
> > Please don't do this. I really like smart home/end.
> > Besides, you already have the option to turn it off, if you don't like
> > it. You can add screen_home/screen_end, that won't hurt.
> > 
> > The first/last non-whitespace behaviour I have seen in many editors. I
> > thought users would be familiar with it.
>
>Ok then, how about I change home to first go to the first non-whitespace
>character, then the beginning of the line, and then the start of the
>viewscreen. A separate keystroke will then be used to go to the start
>of the buffer. Same for end. Sounds like a good idea?
>
>Slava
>
>-- 
>-----------------------------------------------
>jEdit Developers' List
>jEd...@li...
>http://lists.sourceforge.net/mailman/listinfo/jedit-devel

I'm an old Brief user from way back (when it used to be owned
by Underware Software - still love the pun even after 10 years)

They were, I believe, the first to implement the smart home -
start of line - start of screen - start of document (and similar
for end).  They were certainly the first to do it on the pc.

I still love that functionality - one of the things that they did that
most imitators never figured out as being a "good" thing was the 
following:

The behavior of the smart end was based ONLY on the number
of times you hit the key - not at all where you were on the line
or on the screen.  Thus if you hit it once you will be at the end
of the current line EVEN if you started there (almost no smart 
end does this currently!) if you hit it again you were at the end
of the line on the last line on the screen EVEN if you started there
etc.

This was very, very important functionality it allowed you to type
and write macros (recorded macros) and not care about where you
were on the line.  With current implementations there is no way to
get to the end of the line and be sure of getting there unless I know
where I currently am.  I don't like this.  But I do love the smart end in
concept - and I think it would be a big feature to remove if it was taken
out.

Just my $.02 

May all your edits lack typoos,
Hogan

Dirk Moebius wrote:
> Please don't do this. I really like smart home/end.
> Besides, you already have the option to turn it off, if you don't like
> it. You can add screen_home/screen_end, that won't hurt.
> 
> The first/last non-whitespace behaviour I have seen in many editors. I
> thought users would be familiar with it.

Ok then, how about I change home to first go to the first non-whitespace
character, then the beginning of the line, and then the start of the
viewscreen. A separate keystroke will then be used to go to the start
of the buffer. Same for end. Sounds like a good idea?

Slava

I have noticed that when I connect to my linux box using the ftp 
vfilesystem, that the file name for the symlinks include a -> and the 
path to the actual file that the symlink represents.  I don't know if it 
does this for every ftp server with symlinks, but I think this could be 
used to allow the ftp vfilesystem to follow symlinks....
---------------------------------------------------------
"Clothes make the man, naked people have little or no 
influence on society" --Mark Twain--

Nathan Tenney
Computer Specialist
K-SAR Video Productions
Utah State University
na...@rv...