Accepted, Not Yet Planned

We have accepted this to the XPP Product Backlog but have not yet assigned it to a version release.

Extending/Enhancing XPP frills processing

Frills processing has been a long time with us and it has been a very useful 'extension' to XPP.
However there are a lot of limitations in the current implementations.
If only we would have:

  1. Allow for multiple fg macros on the same line each triggering its own 'event'
  2. Add an action number to the fg macro (fg;1, fg;2, ...) allowing a direct detection of the action needed for a particular flag event
  3. Allow for the detection of the horizontal position in the current line of the fg macro
  4. Allow one to read the content of the current line
  5. Allow frills processing to jump to the next flag event instead of forcing us to open each line and check if a flag is set or not
    (believe me writing a routine that really runs through all possible streams, blocks and lines is kind of a dark art full of surprises)

I think that the switch in interface from having to run through all lines to an interface that can simply jump to the next (flag) event might be the more important one.
It would make things a lot simpler for the poor style writer and maybe who knows maybe quicker as well. Could be as simple as:

while ($X->get_next(!flag)) {
 my $action = $X->get_var(!action);
 doSidenote if ($action == 1):
 doBox if ($action == 2)
 ...
}

Another thing that would make life of the poor style writer easier would be adding of an action number to the flag macro.
Or one can take this idea a little further and why not in stead of an action number simply have an action name. And the action would simply call that named xyPerl routine if one would call out the 'next' event.

The next revolutionary thing that creates a lot of new possibilities is to let go the idea of 1 flag = 1 line but allow for multiple (different action) flags on the same line as well as giving the possibility to detect the horizontal position of the flag in the current line. Having access to the horizontal position of the fg macro opens up a lot of new possibilities.

Another thing that would be useful is to have access to the content of the current line. One would not have to store things in the px;;0 register but could extract the information needed by examining the current line. (and yes the part of the line one needs would still have to marked some way or the other). This could be a nice solution in order to work around the limitation of a single px;;0 register/line.

Well that is pretty much it for the moment.
Feel free to add your own wishes or thoughts or remarks.
I will certainly do that myself if I can think of anything else that could be useful

Bart Terryn
Parents

  • Ok thought this over a little more.
    I would like to rearrange the order of requested features and drop maybe some of the more exotic requests.
    My current wish list looks like:

    1. Allow frills processing to jump to the next flag event instead of forcing us to open each line and check if a flag is set or not
    2. Add an 'id' number to the fg macro (<fg;1>, <fg;2>  allowing a direct detection of the action needed for a particular flag event
    3. Allow for multiple fg macros on the same line each triggering its own 'event' and 'id'
    4. Allow for the detection of the (final) horizontal position within the current line of the fg macro
    5. Allow one to read the content of the current line

    Now lets us dive a little into each of these points

    1. jump to next flag

    This would make frills processing a lot simpler and at the same time probably a lot more efficient hence quicker.
    In order to avoid working with a predetermined order of opening streams or jumping to places where you do not want to be, one would still be required to open up the correct stream.
    This means the the next_flag function would only work within the current stream.
    If no stream is currently open, by default next_flag function would open up the main stream
    Jumping through all the flags within the main stream on a page would be simply a matter of a very simple loop:

    while ($X->next_flag()) {
    my $id = $X->get_var('!flag');
    if ($id == 1) {
        doBox();
    } elsif ($id == 2) {
        doSideNote;
    }
}

    When you jump to the next flag, the system would automatically open the correct block and line for you. Like that you could still use the traditional methods to move to the previous or next line, block,..

    2. fg macro gets an optional id

    If the id is not given, then by default the flag gets the id = 1.
    Reading out the !flag system variable will return the id as set on the corresponding fg macro.
    This will allow the traditional loop based frills processing to continue to work as before.

    3. Allow for multiple flag on the same line

    Flags can have the same or different id's

    4. detection of the horizontal position of the fg macro in the current line

    I guess you can see why this could be very useful.

    First of all it would allow us to retrieve the 'final' horizontal position of any element that we are interested in, something that during normal compose is impossible as things like %lnwidth return positions based on the optimum spaceband. 

    5. reading content of current line

    In the first place I see this as a way to work around the current limitation that there is only instance of text register 0 per line. Many of us have been confronted with this limitation. 

    If you could read the content (complete with tags and macros) of the flagged line, there is no more need to use the register 0. You could simply filter out the information you need (provided that it is on the current line - which in most cases it would)

    Final remark

    Needless to say that all of this new functionality would only be available to you when you use xyPerl.
    (with the exception of the !flag returning the id of the fg macro)

     Hmmm... I am really looking forward to see the day when all of this is implemented.
    In the mean time do not hesitate to add your own points/features/thoughts to this idea.

Comment

  • Ok thought this over a little more.
    I would like to rearrange the order of requested features and drop maybe some of the more exotic requests.
    My current wish list looks like:

    1. Allow frills processing to jump to the next flag event instead of forcing us to open each line and check if a flag is set or not
    2. Add an 'id' number to the fg macro (<fg;1>, <fg;2>  allowing a direct detection of the action needed for a particular flag event
    3. Allow for multiple fg macros on the same line each triggering its own 'event' and 'id'
    4. Allow for the detection of the (final) horizontal position within the current line of the fg macro
    5. Allow one to read the content of the current line

    Now lets us dive a little into each of these points

    1. jump to next flag

    This would make frills processing a lot simpler and at the same time probably a lot more efficient hence quicker.
    In order to avoid working with a predetermined order of opening streams or jumping to places where you do not want to be, one would still be required to open up the correct stream.
    This means the the next_flag function would only work within the current stream.
    If no stream is currently open, by default next_flag function would open up the main stream
    Jumping through all the flags within the main stream on a page would be simply a matter of a very simple loop:

    while ($X->next_flag()) {
    my $id = $X->get_var('!flag');
    if ($id == 1) {
        doBox();
    } elsif ($id == 2) {
        doSideNote;
    }
}

    When you jump to the next flag, the system would automatically open the correct block and line for you. Like that you could still use the traditional methods to move to the previous or next line, block,..

    2. fg macro gets an optional id

    If the id is not given, then by default the flag gets the id = 1.
    Reading out the !flag system variable will return the id as set on the corresponding fg macro.
    This will allow the traditional loop based frills processing to continue to work as before.

    3. Allow for multiple flag on the same line

    Flags can have the same or different id's

    4. detection of the horizontal position of the fg macro in the current line

    I guess you can see why this could be very useful.

    First of all it would allow us to retrieve the 'final' horizontal position of any element that we are interested in, something that during normal compose is impossible as things like %lnwidth return positions based on the optimum spaceband. 

    5. reading content of current line

    In the first place I see this as a way to work around the current limitation that there is only instance of text register 0 per line. Many of us have been confronted with this limitation. 

    If you could read the content (complete with tags and macros) of the flagged line, there is no more need to use the register 0. You could simply filter out the information you need (provided that it is on the current line - which in most cases it would)

    Final remark

    Needless to say that all of this new functionality would only be available to you when you use xyPerl.
    (with the exception of the !flag returning the id of the fg macro)

     Hmmm... I am really looking forward to see the day when all of this is implemented.
    In the mean time do not hesitate to add your own points/features/thoughts to this idea.

Children
  • in reply to Bart Terryn

    And a little addition to point 1: jump to next flag.
    I think it would be nice if we can limit the next flag function to a certain stream.
    So the code could become something like:

    while ($X->next_flag('main')) {
    my $id = $X->get_var('!flag');
    if ($id == 1) {
        doBox();
    } elsif ($id == 2) {
        doSideNote;
    }
}

    A $X->next_flag('main') would limit the things to the 'main' stream.

    The $X->next_flag() without a stream argument would go over all the streams and give us the next flag where ever that flag occurs.
    Which raises the question in which order these would happen, I have no opinion on this one....:(I know that is rather exceptional :-).