--- Francois Maltey <[EMAIL PROTECTED]> wrote:
> C Y <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer