axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Emacs updates, fixes


From: C Y
Subject: Re: [Axiom-developer] Emacs updates, fixes
Date: Fri, 12 May 2006 14:28:34 -0700 (PDT)

--- Francois Maltey <address@hidden> wrote:

> Hello,
> 
> I test the axiommode again.
> 
> You correct main bugs. The display is much better.

Ah, good.  Thanks.
 
> Even if you rewrite arrows functions there are others cursor command,
> as [meta >], [meta <], [ctrl N], [ctrl F].

Do they cause problems?

I never intended to restrict ALL keys - in fact, Jay suggested that
some people interact with Emacs entirely without the mouse.  So I have
tried to make things convenient without being overly restrictive.

> // 1 // 
> The first axiom-output before (1) -> isn't write-protect.
> You may write-protect it.

Probably a good idea - I wasn't sure about that.

> // 2 // 
> Can you detect the real pair (input-command, output-command) ?

Sorry, I don't understand what you are asking here.

> So I test 
> [axiom-mode]
> 123 [return]
> [key up]  the cursor is on 123
> 999 [return]
> I get 
> 
> (1) -> 999123
> [result] (2) 999123
> (3) -> [input line]
> [result] (1) 123
> (2) -> 

What should happen if you do that (if I follow you correctly) is
something like the following:

From:

(1) -> 123
     (1) 123
(2) -> [cursor]

to

(1) -> <red 999[cursor]123 red>
     (1) 123
(2) -> 

to

(2) -> 999123
     (2) 999123
(3) -> [cursor]


> Is it possible to get 
> (1) -> 123 [the old input]
> [result] (1) 123 [the old result]
> (2) -> 999123 [the corrected input, with the good prompt]
> [result] (2) 999123
> (3) -> [axiom is now waiting]

You mean the following?

(1) -> 123
     (1) 123
(2) -> 999123
     (2) 999123
(3) -> [cursor]

Right now it is not.  I specifically wanted to overwrite old
input-output combinations, like most modern notebook interfaces.  Are
you saying you want to be unable to overwrite any input-output
combination?  In my experience that usually leads to messy workspaces. 
The commands are present in the history if you wish to recall them - is
something more needed?

> Remember the real input (123 before modification) is possible
> if every input is put in a property of a read-only text, by example
> in the prompt :
> 
> (put-text-property [beginning-of-the-prompt] [end-of-the-prompt] 
>  'data-for-axiom "the-string 1+23")

What do you mean by "real input?"  (1) is gone, except perhaps
somewhere in Axiom's memory.  Why do you want to view it again?  The
whole point of being able to re-evaluate old inputs, in my view, is to
overwrite them.  Otherwise, why not use the new input prompt at the
end?

I'm not sure how to capture a string from the buffer and put it in a
variable - is "the-string 1+23" a way to do this?  

> When you want to recall the initial display you get it by
> (get-text-property [beginning-of-the-prompt] 'data-for-axiom)
>   Before you save the new command-line
>   then you display the initial command-line.
>   You go to the end of the current output
>   Move the current prompt to this place
>   Insert and save with put-text-property the new command
>   Compute-it

Yes, that might be a way to do it, but personally I prefer NOT to have
that behavior.  I might be able to work out something as an option, but
can I ask why you want this?

> // 3 //
> The left key is right in all input area, but the right-key go outside
> the input area inside the prior calculus.

That was at Jay's suggestion, actually.  I used to confine it to the
input only, but he pointed out that for those who don't use the mouse
such a restriction wasn't terribly useful.  The read-only protection
handles preventing any changes.

> // 4 //
> You disallow the selection of output-data. A great idea.
> So the [return] key must do nothing when you aren't between a prompt 
> (n) -> and an empty-line. (or over read-only area)

Point. Hmm...

> But : 
> [axiom-mode] 123 [return]
> [ctrl-p] 
> Then the cursor is inside the last line (Type: PositiveInteger) 
> and the return key accept it. 
> Axiom-mode may reject a command copyed from this output area.

Really.  Another thing I don't think I tried.  I'll see if I can
duplicate what you describe.

> // 5 // 
> I don't understand the aim of the sit-for functions.
> Are they necessary ?

Don't know.  They came from Jay, and I hesitate to monkey too much with
them.

> In my emacs programs (for mupad), sit-for allows recursive calls
> during inserting results and I get currious error.
> 
> // 6 //
> Must I get the same result 
> with commint-mode / commint-run / axiom and axiom-mode ?

Um - what were you hoping for?  Do you mean you WANT the same result? 
I can link axiom and axiom-mode together perhaps, but comint-mode is a
separate mode altogether and is used by more than just Axiom.

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]