Re: [Axiom-developer] Emacs updates, fixes

[C Y]

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

> C Y <address@hidden> writes:
> 
> > I never intended to restrict ALL keys
> I agree, it's the right way, because it's almost impossible 
> to lock ALL emacs keys.
> 
> So axiom-mode MUST be able to recognize that the cursor is 
> outside an input area. 

That's a bit difficult but I think it can be managed.  I suspect
mmm-mode might be of some service there, if I can ever figure it out
:-/.  Rather than piling on lots of tricks I would prefer to do so once
per "environment" to identify input prompts, output regions, etc and
then all special commands can be part of "sub-modes".  (syntax
highlighting, for example).

> > > // 2 // 

> > You mean the following?
> > 
> > (1) -> 123
> >      (1) 123
> > (2) -> 999123
> >      (2) 999123
> > (3) -> [cursor]
> 
> Yes 
> 
> > 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?  
> 
> Yes.
> I prefer to keep previous commands on the terminal because I really
> see what I (and students) type before the last correction.
> So I find the errors more quickly.

Hmm.  OK, I can see that.  I should be able to do it as an option.

> > 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?
> 
> > 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?  
> 
> It's nice to see it always because it's perhaps somewhere in
> Axiom's memory. So I find the bugs of my students if I see the
> history.

OK.
 
> (buffer-substring 1 122) get the beginning of the buffer.
> (setq var (buffer-substring 1 122))

Ah, excellent.  Thanks!
 
> > 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?
> 
> I understand your point of view.
> 
> If you want short workspace, it's also possible to hide only the
> output with a delete-region, and put the substring of the deleted 
> region in the prompt with put-text-property. And get it back again
> with a (insert (get-text-property...)) if the user wants to make it 
> visible again.

I'm not after short so much as I'm after neat - at the end I have only
the commands I need to achieve the result I'm after.  Of course, you
have a point about losing things you might need later - or at least,
making them harder to track down.

> I use maple too often and I disapprove interfaces with re-evaluate.

OK.  That's a reasonable end user request, particularly from someone
who took the trouble to create their own Axiom mode ;-).  I'll see what
I can do about adding it.

One other possible option would be a "sticky prompt" - rather than
having the up arrow return to the previous input lines, it could
instead take the current prompt and insert it back further in the
document.  

> And for my use I prefer buffer where nothing can be change
> after the computation, as a typewriter.

OK.

> > Yes, that might be a way to do it, but personally I prefer NOT to
> > have that behavior.
> 
> I accept your point of view, but try to keep the _possibility_ to 
> have an axiom-mode where re-evaluate is impossible.

I'll plan to add it as an option that can be triggered via a .emacs
file, if that's acceptable.

> > > // 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 have no hope, I only want to know if I can compare
> axiom-mode result and comint result in order to understand 
> how axiom-mode is working.

Uh.  comint mode doesn't really do anything by itself - it's just an IO
framework, pretty much.  I'm basically using it without delving any
deeper into its guts than I need to.

> You make a really big work. Continue to send new versions, I try to
> understand axiom-mode.el with the diff command.

That will just point out all of my dumb mistakes :-).  I'm trying to
get to a "regrouping" point where I can leave the "working" version
alone for a while and re-structure based on what I have learned thus
far.  I can feel the "literate" quality of this code getting away from
me as things like the eval command expand in size, so I need to put the
brakes on and get it back under control.

Cheers,
CY

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