cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

trouble with named paste buffers and current_doc

JeffStevenson
2-Guest

trouble with named paste buffers and current_doc

Hey folks,

I'm trying to work with named paste buffers in a callback to manipulate content before it is output to the current doc.

I'm finding that Arbortext is getting confused on which is the current doc depending upon what actions I'm performing.

For instance, if I do oid_delete(some_oid), it removes the oid from the buffer. However, if I do a change_tag, it wants to act upon the document currently open in the window. I thought this was perhaps an issue with commands versus functions, but goto_oid() also works in the document window rather than the buffer.

Here is a snippet of my code where I am setting things up with the named buffer.

buffer_create("_temp_");

set paste = "_temp_";

local bufstr;

buffer_clipboard_contents(bufstr);

insert_buffer(bufstr,1,"_temp_");

local pdoc = buffer_doc("_temp_");

local root = oid_first(pdoc);

The oid_first() function works OK. This would lead me to think that Arbortext has picked up on the named buffer as the current doc, but as I described, it gets flakey. I've tried a current_doc(pdoc), but no luck.

Any ideas are much appreciated!

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Jeff--

In a case like this, it pays to be explicit about the current doc.After you create your named buffer, add this:

     local buffdoc = buffer_doc("_temp_");

     local savedoc = current_doc(buffdoc);

Now the buffer document has been explicitly set as the current document. When you are done monkeying around with the buffer contents and want to switch back to the main document, use this:

     current_doc(savedoc);

This idiom is used extensively in the Arbortext core ACL code.

--Clay

View solution in original post

5 REPLIES 5

Hi Jeff--

In a case like this, it pays to be explicit about the current doc.After you create your named buffer, add this:

     local buffdoc = buffer_doc("_temp_");

     local savedoc = current_doc(buffdoc);

Now the buffer document has been explicitly set as the current document. When you are done monkeying around with the buffer contents and want to switch back to the main document, use this:

     current_doc(savedoc);

This idiom is used extensively in the Arbortext core ACL code.

--Clay

View solution in original post

BTW, the reason your oid_first() call works the way you expect is because you are explicitly telling it to act on the buffer document by passing the pdoc parameter. That method should also work for many other function calls, as long as they provide an optional parameter for specifying the doc ID. But some functions, and most commands, don't provide such a parameter, so it's safest to use the current_doc() function to set the current document.

--C

Hi Clay,

I tried something similar with current_doc but it still wanted to work with the doc window document.

In your sample, wouldn't you want local savedoc = current_doc(buffdoc); to the original document id rather than the buffer doc id?

-Jeff

Hi Jeff--

Taking things backwards, when you call current_doc() with a doc ID parameter, it does two things:

  1. It sets the current document to the doc ID you specified, and
  2. It returns the doc ID of the previously current document (in this case, presumably the editor doc)

So, the code as written will do exactly what you suggest. Seriously, this idiom appears *all over* the base ACL code. Grep for "savedoc" in $ARBORTEXT/packages/* and you'll get zillions of hits.

For the first thing, I'm not sure what might have been going wrong there. (But maybe your second question indicates an incorrect understanding of how current_doc() works, such that you weren't actually setting it to the buffer document when you thought you were?) A few things to consider:

  • Some editing commands are focused on window rather than document. If a command isn't respecting your setting of current_doc(), then see if you can find an analogous function. YMMV, but I find functions to be a bit more transparent in how they determine the target of their effects than commands are. (For most commands that modify the document, there are similar functions that can be used, and that often give you greater control of the operation.) For example, there is an "insert" command, but there is also an insert() function, which takes an optional destination parameter for a doc ID.
  • When working with OIDs, the doc ID is an integral part of the OID. You will probably have problems if you try to use an OID generated from the main document to do something with content in a paste buffer, even if the paste buffer contains a copy of the same content referred to by the OID. If you are working in a buffer document, get your OIDs from the buffer document.
  • Many functions take a doc parameter to specify a target document. The doc parameter is often optional, so it's easy to forget it's there, but in situations like this, take advantage of these as much as possible.

Hopefully something here will be helpful enough to get you over the hump.

--Clay

Thanks, Clay. I wasn't aware of the 2nd point where current_doc returns doc ID of the previous doc. I thought it returned the doc id of the doc that is being set.

Much thanks!

Announcements