Re: [Texmacs-dev] operation on the selection

[Nix N. Nix]

On Sun, 2003-03-23 at 07:48, address@hidden wrote:
> On Fri, Mar 21, 2003 at 02:43:43PM -0700, Nix N. Nix wrote:
> > On Fri, 2003-03-21 at 04:34, address@hidden wrote:
> > 
> > > Generally, it would be nice to have simple and efficient mechanisms to
> > > operate on the selection from Scheme. I can think of three approaches,
> > > each useful for a different purpose:
> > 
> > I agree.  Before I decided to use cut and paste, I was looking through
> > the Scheme code for a (get-selection) (kill-selection)
> > (insert-selection) combo, but couldn't find one.  Kill selection is
> > already there in the form of Edit -> Clear (although it doesn't work). 
> 
> Actually, there is lot of confusion in TeXmacs between selections and
> clipboards.
> 
> Edit->Clear just clears the primary clipboard... I know that is
> useless, but at least one other person believes that is fine.

Oh - that's dumb ... Isn't the primary cleared before any kind of
copying takes place anyway ?  Isn't the function of clearing the
clipboard beyond the scope of TeXmacs, i.e., shouldn't a clear-clipboard
function be a more generic, desktop-level function, rather than a
TeXmacs function ?

> 
> It should not be too difficult to add a couple of glue accessors
> "selection-start" and "selection-end" to get the paths of the bounds
> of the current selection.

Wouldn't it be better to just have a function that simply turns the
current selection into a tree ?  This could even be done during the
process of selection itself, i.e., the tree gets built while the user
performs mouse-drag and/or Shift+Arrow. An added bonus of this would be
something like

(if (null? the_selection)
  (display "We have no selection !\n") 
  (display "We have a selection !\n"))

If we have selection-start and selection-end, we would still have to
traverse the tree from selection-start to selection-end and construct
another tree from that on our own time - if I'm not mistaken.

> 
> > I don't know whether we have a way of inserting a tree at the current
> > position, a tree such as the one that would be produced by an equally
> > unavailable function, such as (get-selection).
> 
> I did not check about get-selection (not to be understood as
> get-clipboard). Structural insertion can be done with fundamental tree
> operators (tm-assign, tm-remove, tm-insert, tm-join, tm-split,
> tm-ins-unary, tm-rem-unary). Beware though, that these procedures make
> no kind of sanity check whatsoever.

Ooooh ! There's also (insert-tree-at t p).  I wonder if that'd be
useful.  If so, all we need now is a function that will turn the current
selection into a tree that can be passed to this function.

> 
> 
> > Also, for some reason, in the (make-brackets) code, I tried using
> > (cursor-left) in order for the cursor to end up in between the left and
> > right brackets at the end of the execution of the function.  That didn't
> > work, for some reason.
> 
> Visual motion commands are disable between any modification to the
> document tree and the refreshing of the box tree, which is done in the
> main event loop. However, you can still use structural motion commands
> (tm-go-to).

Oh, I see.  However, this does not work either:

(define (make-brackets left right)
  (if (selection-active-normal?)
    (begin (cut "primary") (make-large-left left) (paste "primary")
           (let* ((pos (tm-position-new)) (old (tm-position-get pos)))
             (make-large-right right)
             (tm-go-to old)
             (tm-position-delete pos)))
    (begin (make-large-left left)
           (let* ((pos (tm-position-new)) (old (tm-position-get pos)))
             (make-large-right right) 
             (tm-go-to old) 
             (tm-position-delete pos)))))

[...]