Donald Bruce Stewart | 7 Nov 2004 09:06
Picon
Picon
Favicon
Gravatar

:map and :unmap


Ok, here's an initial vi-style :map and :unmap (nullary macros). This
probably works for emacs too (?)

To set a key mapping (ie. :map f jjjj) we execute the current lexer with
just "jjjj" as input, returning a list of [Action] that would occur if
that input had been entered. We then concat those actions with (>>),
getting a single action that is used to generate a new lexer (the `bind'
below).  Finally, we add the new binding to the current lexer with >||<.

        eval_map :: ViMode -> [Char] -> [Char] -> ViMode
        eval_map cmdm lhs rhs = cmdm >||< bind 
            where
                (as,_,_) = execLexer cmdm (rhs, (St [] cmdm))
                bind     = string lhs `action` \_ -> Just (foldl1 (>>) as)

Now, to unmap, we execute the original lexer with the binding (i.e. "f")
getting back any action that 'f' was previously bound to. We then rebind
'f' to that old action, if any. Ideally we need to store a stack of
previous lexers so we could have stacked bindings, but for now we just
execute the original lexer.

eval_unmap :: ViMode -> [Char] -> ViMode
eval_unmap cmdm lhs = cmdm >||< bind
    where
        (as,_,_) = execLexer cmd_mode{-original-} (lhs, (St [] cmd_mode))
        bind     = case as of
                    [] -> string lhs `action` \_ -> Just nopE -- wasn't bound prior
                    [a]-> string lhs `action` \_ -> Just a    -- bound to just one
                    _  -> string lhs `action` \_ -> Just nopE
(Continue reading)

Donald Bruce Stewart | 7 Nov 2004 03:10
Picon
Picon
Favicon
Gravatar

User-added bindings, runtime Haskell


With the new lexer framework, we can easily add new bindings to yi at
run time or in config files, like so.

A user defined binding added to the vi mode:

    module Config where

    import Yi.Yi
    import qualified Yi.Keymap.Vi as Vi

    yi = settings {
        keymap = Vi.keymapPlus mybinds
    }

    mybinds = char 'n'
              `action` \_ -> Just $ mapM_ insertE "yi rules"

The user imports the keymap they wish to work from, and then adds an
extra entry to the lexer table (an `action`) using keymapPlus, which
augments the base lexer:

    module Yi.Keymap.Vi where

    keymapPlus :: ViMode -> [Char] -> IO ()
    keymapPlus l cs = mapM_ (>> refreshE) actions
        where
            actions = let (ts,_,_) = execLexer (lexer >||< l) (cs, emptySt) 
                      in ts
            emptySt = []
(Continue reading)

Simon Winwood | 5 Nov 2004 08:33
Picon
Picon
Favicon

Commands


	Hi, one of the things that makes emacs so cool is its inbuilt
documentation.  I'm not sure how close Yi can get to emacs in this
regard, but one option would be to define a Command type, something
like:

-- Action does something in the IO monad and returns it's inverse, if
-- it exists
data Action = AC (IO (Maybe Action))

data Command = Command String String  Action
--                     Name   Comment

The comment can be generated from Haddock etc.  The idea is
that keys can be bound to objects of type Command, and that M-x (e.g.)
can then invoke based on the name of the function.  

A (stupid) example:

defineCommand $ Command "insertLetterA" "Insert the letter `A'" (insertA 'A')

where 

-- The insert action
insertA x = insertE x >> return deleteA

-- The delete action
deleteA = readE >>= ( \c -> deleteE >> return (insertA c))

To do undo, we can then fiddle around with monads, so that built-up
(Continue reading)

Donald Bruce Stewart | 4 Nov 2004 08:47
Picon
Picon
Favicon
Gravatar

Lazy key strokes


As first part of the push to make keymaps more functional, more fun in yi, we
can read all the keystrokes a user might enter lazily into a string, and pass
that to the keymap/lexer. That way the lexer will demand new keys as required,
without us having to manage our own getChars/getcE lookaheads. This is really
nice. Should be able to use real lexers on this kind of input.

Who votes for lazy input? :D

        eventLoop :: IO ()
        eventLoop = do
            let loop = do catchJust (ioErrors) (lazyRead >>= fn) (handler)
                          loop
            loop
            where handler = \e -> msgE (show e)

                  -- quick hack
                  fn ('h':cs)     = leftOrSolE 1    >> UI.refresh >> fn cs
                  fn ('j':cs)     = downE           >> UI.refresh >> fn cs
                  fn ('k':cs)     = upE             >> UI.refresh >> fn cs
                  fn ('l':cs)     = rightOrEolE 1   >> UI.refresh >> fn cs
                  fn ('Z':'Z':cs) = quitE           >> UI.refresh >> fn cs
                  fn (':':'w':'q':cs) = quitE       >> UI.refresh >> fn cs
                  fn (c:cs)       = msgE (show c)   >> fn cs

        -- | Lazily read all input from the user. A big magic.
        lazyRead :: IO String
        lazyRead = unsafeInterleaveIO $ do
                        c  <- getcE
                        cs <- lazyRead
(Continue reading)

Jeremy Shaw | 4 Nov 2004 03:01

alternate Emacs keymap

Hello,

Attached is an emacs keymap I made before yi came with one. A couple
people on irc asked to see this code, so I am sending it around.  It
is similar to the existing Emacs keymap, but does not use any
IORef's. However, that does not mean it is better, just different...

The code really needs some work to make it more readable, but that
seems a bit premature at this point in time.

The features of emacs that I have partially mimic'd are:

 ~ simple navigation, delete, backspace, and inserting text

 ~ Showing what you have typed so far for compound key commands (for
 example, hit C-x).

 ~ C-h k (aka, describe-key) -- however, unlike emacs, I just show the
 keycode of the next key pressed.

 ~ Keys can be rebound on the fly (though I don't provide a way to
 actually do that yet).

I think the most interesting part to work on is to try to get
reasonable clones of describe-key and set-global-key working, because
that requires someway to assign text names and descriptions to
functions.

Also, as written, the describeKey function is really tricky, with all
sorts of nested returns and constructors. If I continue down this
(Continue reading)

Shae Matijs Erisson | 3 Nov 2004 00:57

Fixed list Archives

Finally, I have fixed the list archives:
http://lists.scannedinavian.org/pipermail/post-emacs/
--

-- 
Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/
"I will, as we say in rock 'n' roll, run until the wheels come off, 
because I love what I do." -- David Crosby
Donald Bruce Stewart | 21 Oct 2004 08:26
Picon
Picon
Favicon
Gravatar

undo/redo


Undo/Redo when using mutable buffers:

* Have a list for undo and redo actions.

* When you perform an action, add the function that performs the
inverse to the undo list, and the function itself to the redo list.

E.g:
        e_insert :: Char -> Int -> Buffer -> IO ()
        e_insert c i b = 
                let fn = Buffer.insert c i buf
                    fn'= Buffer.delete c i buf
                in do
                    withRedo $ \redo -> fn : redo
                    withUndo $ \undo -> fn': undo
                    fn :: IO ()

Thoughts?

-- Don
Tuomo Valkonen | 19 Oct 2004 09:13
Picon
Picon

A theory of buffers


A theory of buffers (is just a theory of patches à la darcs)

All sorts of buffer modes and other transformations could be quite cleanly
handled with a "theory of patches" sort of approach. Namely, buffers should
considered a sequence of transformations (of two flavours: primitive/patch
and higher-level structural transformations). 

In a normal simple setup, initially, the first transformation would be the
one that patches an empty transformation to the initial contents of the file
being edited. After that there could be a character set conversion
transformation, then a language mode transformation to convert plaintext to
a structure, then a folding transformation to hide part of that structure,
and finally syntax highlighting transformation for turning that structure
back into a form easily digested by the UI.

= Basic modications =

Now, when the user wihes to edit the file, the UI generates a patch (or
primitive transformation) against the output of the SyntaxHighlighting
transformation. Here's what the the list of transformation would look like
then:

    Plaintext "filename"
    Conversion "utf-8"
    HaskellMode
    Folding
    SyntaxHighlighting
    PrimTrans

(Continue reading)

Einar Karttunen | 17 Oct 2004 19:07
Picon
Picon
Favicon

Buffers

Hello 

There are several different ways of implementing syntax highlighting,
folding etc. Most non-trivial modes need to structure the text in
order to highlit it, and even text movement commands need to observe
some structure in the text.

Most editors today treat the buffer as a flat text string with parts
decorated with various attributes like color, font-size or link target.

The alternative is to make a common shared structure which different
modes can use. This will make it easier to define generic operations
and if implemented in the right way should make writing apps inside
the editor easier.

A natural structure would be N-ary trees (or do we need graphs?), with
nodes conforming to a specified interface i.e. not necessarily plain
text. 

If the nodes are typeable then many operations can be expressed quite
simply:

e.g. 

data Folded = Folded Node
foldNode = Folded
unfoldNode node = maybe node (\(Folded d) -> d) (cast node)

Implementing the interface can be done in a variety of ways:
* class Node 
(Continue reading)

Einar Karttunen | 17 Oct 2004 19:07
Picon
Picon
Favicon

Editor texts for reading

Hello 

Just some links on different stuff:

Acme contained a very different user interface 
gathering many fans.

Acme - An User Interface for Programmers

http://www.cs.bell-labs.com/sys/doc/acme/acme.html
http://www.cs.bell-labs.com/sys/doc/acme/acme.ps
http://www.cs.bell-labs.com/sys/doc/acme/acme.pdf

Sam is old and not very usefull, however the 
design had nice backend/frontend separation.

The Text Editor sam

http://www.cs.bell-labs.com/sys/doc/sam/sam.html
http://www.cs.bell-labs.com/sys/doc/sam/sam.ps
http://www.cs.bell-labs.com/sys/doc/sam/sam.pdf

- Einar Karttunen
Shae Matijs Erisson | 17 Oct 2004 19:04

mail test...

testing post-emacs@...
--

-- 
Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/
"I will, as we say in rock 'n' roll, run until the wheels come off, 
because I love what I do." -- David Crosby

Gmane