headers
Peter Graves | 1 Apr 2005 15:49

Re: [j-users] Minority problem? Need to disable antialiasing under MacOSX

On Fri, 01 Apr 2005 at 02:37:50 +0200, stso <at> gmx.at wrote:
> But .. unfortunately, my special need is to _disable_ antialiasing on 
> the Mac powerbook that I (have to) use sometimes.
>
> I selected the appropriate settings in Tinker Tools, now each and 
> every application uses non-antialiased fonts ... except J....
>
> Is there anything that can be done about that?
>
> Of course I tried the antialias key in .j/prefs. No effect.

That's odd.

The antialias property defaults to false (Property.java:88), and it
will stay false unless you put a line like this in ~/.j/prefs:

    antialias = true

All the places that j turns on antialiasing are in Display.java (search
for "antialias" and you'll find them), and they're all controlled by
the aforementioned antialias property.

So unless you change ~/.j/prefs to turn on antialiasing, j is simply
using the default settings for the version of Java you're using and the
platform you're on.

It's entirely possible that the version of Java you're using on OS X
turns on antialiasing by default, and there may be some specific magic
you can do to turn it off. Maybe there's a property you can set on the
command line that runs Java when you start up j, or there might even be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Warner | 1 Apr 2005 15:09
Picon

Yes! (specialised arrays)

Hi Peter,

Just this moment I was trying to decide what to do about implementations
that couldn't distinguish between arrays of (UNSIGNED-BYTE 8) and T. And
then I did a cvs up of J and noticed these wonderful filenames:

U src/org/armedbear/lisp/SimpleArray_T.java
U src/org/armedbear/lisp/SimpleArray_UnsignedByte32.java
U src/org/armedbear/lisp/SimpleArray_UnsignedByte8.java

And it's working:

CL-USER(1): (make-array 10 :element-type '(unsigned-byte 8))
#(0 0 0 0 0 0 0 0 0 0)
CL-USER(2): (type-of *)
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (10))
CL-USER(3): (make-array 10 :element-type '(unsigned-byte 16))
#(0 0 0 0 0 0 0 0 0 0)
CL-USER(4): (type-of *)
(SIMPLE-ARRAY (UNSIGNED-BYTE 32) (10))

I'm glad you worked around the Java/JVM treatment of 8-bit arrays as
signed.

I note there's no sub-FIXNUM error checking upon setting array values (the
result is modulus the byte size):

CL-USER(19): (defparameter *x* (make-array 1 :element-type '(unsigned-byte 8)))
*X*
CL-USER(20): (setf (aref *x* 0) 257)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Graves | 3 Apr 2005 16:14

Re: Yes! (specialised arrays)

On Sat, 02 Apr 2005 at 01:09:32 +1200, Adam Warner wrote:
> Just this moment I was trying to decide what to do about implementations
> that couldn't distinguish between arrays of (UNSIGNED-BYTE 8) and T. And
> then I did a cvs up of J and noticed these wonderful filenames:
>
> U src/org/armedbear/lisp/SimpleArray_T.java
> U src/org/armedbear/lisp/SimpleArray_UnsignedByte32.java
> U src/org/armedbear/lisp/SimpleArray_UnsignedByte8.java
>
> And it's working:
>
> CL-USER(1): (make-array 10 :element-type '(unsigned-byte 8))
> #(0 0 0 0 0 0 0 0 0 0)
> CL-USER(2): (type-of *)
> (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (10))
> CL-USER(3): (make-array 10 :element-type '(unsigned-byte 16))
> #(0 0 0 0 0 0 0 0 0 0)
> CL-USER(4): (type-of *)
> (SIMPLE-ARRAY (UNSIGNED-BYTE 32) (10))

Yeah. These specialized array types were needed for the build-sbcl
project.

I'm still not sure exactly why, however. In particular, abcl's
unsigned-byte 32 vectors are currently entirely bogus, in the sense
that they're really just simple-vectors lying about their upgraded
element type, and that approach seems OK with sbcl (although there are
still other problems that prevent build-sbcl from reaching a successful
end). I'm really not sure why sbcl insists that the host Lisp provide
these array types.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Graves | 5 Apr 2005 03:38

Bug 1175869 (can't save a new session with a new name)

On Sun, 03 Apr 2005 at 09:20:48 -0700, SourceForge.net wrote:
> Bugs item #1175869, was opened at 2005-04-03 17:20
> Message generated for change (Tracker Item Submitted) made by Item Submitter
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=475785&aid=1175869&group_id=55057
>
> Category: Editor
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Pete Kirkham (machineelf)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: can't save a new session with a new name
>
> Initial Comment:
> Often I have several session's I'm using throughout the
> editor uptime. At the moment, once you have saved or
> opened a session, you aren't prompted to enter the
> session name when you save again; so if I'm starting a
> new session, I have to close all, exit J then come in
> again.
>
> Fix: file>Close All clears the current session name as
> well as closing all files
>
> add 
>
> setSessionName(null);
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Graves | 5 Apr 2005 03:24

Bug 881734 (OS X Oddnesses)

An anonymous comment was added to bug 881734 in j's SourceForge bug
tracker this weekend:

    Comment By: Nobody/Anonymous (nobody)
    Date: 2005-04-03 09:02

    Message:
    Logged In: NO 

    I have dynamic menus working - simply rebuilding the menu
    under Apple's 1.4.2 java update now has the desired effect:

    Frame.java:

        public void setMenu()
        {
            final Mode mode = currentEditor.getMode();
            final MenuBar oldMenuBar = (MenuBar) getJMenuBar();
            if (oldMenuBar == null ||
                Platform.isPlatformOS_X() ||
                oldMenuBar.getMenuName() != mode.getMenuName()) {
                setJMenuBar(mode.createMenuBar(this));
                validate();
            }
        }

Since I don't have a Mac myself, I have no idea whether the suggested
change really works, or is a complete solution to the menus-on-OS-X
problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Martin | 8 Apr 2005 18:41
Picon

comments and questions

Hi,

I've recently discovered this editor and I wanted to say how impressed
I am. J seems to capture a lot of the good aspects of emacs, while
avoiding many of its shortcomings. In particular, the buffer-based
directory navigation is a joy to use, and is something I always miss
when using other non-emacs editors and IDE's. Also, although I'm not a
lisper, I really like the approach of combining Java with common lisp.

That said, I have a few questions:

1. Are there any plans to add support for soft line wrapping? To me
this is an important capability, because there are cases (with xslt,
for example), where one cannot avoid having very long lines of text.
If there are no such plans, would there be any objection to my taking
a try at implementing it?

2. Are there any sites containing J extensions beyond what is included
in the distribution?

Thanks,

-Dave Martin

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter Graves | 9 Apr 2005 01:30

Re: comments and questions

On Fri, 8 Apr 2005 at 09:41:49 -0700, David Martin wrote:
> 1. Are there any plans to add support for soft line wrapping? To me
> this is an important capability, because there are cases (with xslt,
> for example), where one cannot avoid having very long lines of text.
> If there are no such plans, would there be any objection to my taking
> a try at implementing it?

Assuming that you mean display-only line wrapping, the way emacs
does it, this feature has been requested and discussed before. See this
thread, for example:

    http://thread.gmane.org/gmane.editors.j.devel/650

In particular:

    It would be, I think, a very big deal to change the display code to
    provide this behavior as an option. There's quite a bit of code
    that relies on a one-to-one correspondence between display lines
    and actual lines of text in editable buffers; basic things like
    cursor movement and selection are sure to break if that assumption
    no longer holds. In theory one could go on to fix the breakage and
    eventually come out on the other side, but it would be an
    architectural change and a big undertaking.

It would be a nice feature to have, but I don't have any plans to do it
myself any time soon. You're certainly welcome to have a crack at it,
but please consider all of the caveats mentioned in the discussion
referenced above.

> 2. Are there any sites containing J extensions beyond what is included
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wayne Rogers | 9 Apr 2005 18:05
Picon
Favicon

Re:comments and questions


< If by extensions you mean someone is embedding j,
then here's something from the pushtotest dev lists:
http://lists.pushtotest.com/pipermail/dev/2004-December.txt
/>

The new version  features a new text editor. I
replaced the existing 
script editor with J, an open-source program editor. J
features syntax 
highlighting, indentation controls, search/replace
(including Regular 
Expressions,) and easy file/method navigation. Details
on J are found 
at http://armedbear-j.sourceforge.net/

--- armedbear-j-devel-request <at> lists.sourceforge.net
wrote:
> Send armedbear-j-devel mailing list submissions to
> 	armedbear-j-devel <at> lists.sourceforge.net
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 
>
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
> or, via email, send a message with subject or body
> 'help' to
> 	armedbear-j-devel-request <at> lists.sourceforge.net
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Peter Graves | 10 Apr 2005 22:54

Re: comments and questions

On Sun, 10 Apr 2005 at 12:02:49 -0700, David Martin wrote:
> Thanks, Peter. I must have missed that thread in my archive search. I
> still might give it a try, or at least mess around with it until I get
> a better idea of how significant the changes would have to be. Would
> any of the lisp code be affected, or just the Java?

A good place to start would be Display.java. The Lisp code should not
be an issue; it basically just provides wrappers of the Java code for
the relevant functionality.

-Peter

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 0 comments |
headers
David Martin | 10 Apr 2005 21:02
Picon

Re: comments and questions

Thanks, Peter. I must have missed that thread in my archive search. I
still might give it a try, or at least mess around with it until I get
a better idea of how significant the changes would have to be. Would
any of the lisp code be affected, or just the Java?

-Dave

On Apr 8, 2005 4:30 PM, Peter Graves <peter <at> armedbear.org> wrote:
> On Fri, 8 Apr 2005 at 09:41:49 -0700, David Martin wrote:
> > 1. Are there any plans to add support for soft line wrapping? To me
> > this is an important capability, because there are cases (with xslt,
> > for example), where one cannot avoid having very long lines of text.
> > If there are no such plans, would there be any objection to my taking
> > a try at implementing it?
> 
> Assuming that you mean display-only line wrapping, the way emacs
> does it, this feature has been requested and discussed before. See this
> thread, for example:
> 
>     http://thread.gmane.org/gmane.editors.j.devel/650
> 
> In particular:
> 
>     It would be, I think, a very big deal to change the display code to
>     provide this behavior as an option. There's quite a bit of code
>     that relies on a one-to-one correspondence between display lines
>     and actual lines of text in editable buffers; basic things like
>     cursor movement and selection are sure to break if that assumption
>     no longer holds. In theory one could go on to fix the breakage and
>     eventually come out on the other side, but it would be an
(Continue reading)

Permalink | Reply | 1 comment |

Gmane