It is proposed to add two new commands to the text widget:
> _pathName_ **sync** _?-command command?_
> _pathName_ **pendingsync**
Also a new virtual event **<<WidgetViewSync>>** will be added.
Description:
_pathName_ **sync**
Immediately brings the line metrics up-to-date by forcing computation of
any outdated line pixel heights. Indeed, to maintain a responsive
................................................................................
calculations, the scheduling is immediate. The command returns the empty
string. **bgerror** is called on _command_ failure.
_pathName_ **pendingsync**
Returns 1 if the line calculations are not up-to-date, 0 otherwise.
**<<WidgetViewSync>>**
A widget can have a period of time during which the internal data model is
not in sync with the view. The **sync** method forces the view to be in
sync with the data. The **<<WidgetViewSync>>** virtual event fires when
the internal data model starts to be out of sync with the widget view, and
also when it becomes again in sync with the widget view. For the text
widget, it fires when line metrics become outdated, and when they are
up-to-date again. Note that this means it fires in particular when
_pathName_ **sync** returns \(if there was pending updates\). The detail
field \(%d substitution\) is either true \(when the widget is in sync\) or
false \(when it is not\).
All **sync**, **pendingsync** and **<<WidgetViewSync>>** apply to
each text widget independently of its peers.
The names **sync**, **pendingsync** and **<<WidgetViewSync>>** are chosen
because of the potential for generalization to other widgets they have.
The text widget documentation will be augmented by a short section describing
the asynchronous update of line metrics, the reasons for that background
update, the drawbacks regarding possibly wrong results in **.text yview** or
**.text yview moveto**, and the way to solve these issues by using the new
commands. Example code as below will be provided in the documentation, since
................................................................................
number of pixels used by the text widget contents is needed, because this
total pixel height calculation involves the total number of display \(not
logical\) lines. Assessing the total number of display lines has a
performance cost similar to proper line heights calculation, which voids
that path.
* It has been proposed that the detail field %d for the
**<<WidgetViewSync>>** event contain the number of outdated lines, while
this event would fire at each [after 1] partial update of the line metrics.
This was rejected since no use case of this value could be exhibited, and it
was believed that firing the event twice \(when out of sync and when again in
sync\) was sufficient.
* It has been proposed that the **text pendingsync** command return the
number of currently outdated lines. This was rejected because no use case

It is proposed to add two new commands to the text widget:
> _pathName_ **sync** _?-command command?_
> _pathName_ **pendingsync**
Also a new virtual event **\<\<WidgetViewSync\>\>** will be added.
Description:
_pathName_ **sync**
Immediately brings the line metrics up-to-date by forcing computation of
any outdated line pixel heights. Indeed, to maintain a responsive
................................................................................
calculations, the scheduling is immediate. The command returns the empty
string. **bgerror** is called on _command_ failure.
_pathName_ **pendingsync**
Returns 1 if the line calculations are not up-to-date, 0 otherwise.
**\<\<WidgetViewSync\>\>**
A widget can have a period of time during which the internal data model is
not in sync with the view. The **sync** method forces the view to be in
sync with the data. The **<<WidgetViewSync>>** virtual event fires when
the internal data model starts to be out of sync with the widget view, and
also when it becomes again in sync with the widget view. For the text
widget, it fires when line metrics become outdated, and when they are
up-to-date again. Note that this means it fires in particular when
_pathName_ **sync** returns \(if there was pending updates\). The detail
field \(%d substitution\) is either true \(when the widget is in sync\) or
false \(when it is not\).
All **sync**, **pendingsync** and **\<\<WidgetViewSync\>\>** apply to
each text widget independently of its peers.
The names **sync**, **pendingsync** and **\<\<WidgetViewSync\>\>** are chosen
because of the potential for generalization to other widgets they have.
The text widget documentation will be augmented by a short section describing
the asynchronous update of line metrics, the reasons for that background
update, the drawbacks regarding possibly wrong results in **.text yview** or
**.text yview moveto**, and the way to solve these issues by using the new
commands. Example code as below will be provided in the documentation, since
................................................................................
number of pixels used by the text widget contents is needed, because this
total pixel height calculation involves the total number of display \(not
logical\) lines. Assessing the total number of display lines has a
performance cost similar to proper line heights calculation, which voids
that path.
* It has been proposed that the detail field %d for the
**\<\<WidgetViewSync\>\>** event contain the number of outdated lines, while
this event would fire at each [after 1] partial update of the line metrics.
This was rejected since no use case of this value could be exhibited, and it
was believed that firing the event twice \(when out of sync and when again in
sync\) was sufficient.
* It has been proposed that the **text pendingsync** command return the
number of currently outdated lines. This was rejected because no use case