| 2014-09-17 15:17:04 |
KaiMartin |
description |
Autonumber on paste of a copied selection is very ineffcient. It
To reproduce:
1) add the following lines to gschemrc to activate autonumber on insert:
(load-from-path "auto-uref.scm")
(define auto-uref-set-page-offset 100)
(add-hook! add-component-hook auto-uref)
(add-hook! copy-component-hook auto-uref)
2) open a schematic with a decent amount of components (~50 symbols will do)
3) select the whole schematic (e.g. with [ctrl-a])
4) copy the selection to buffer (e.g. with [ctrl-c])
5) paste the buffer at some other place
result: gschem gets unresponsive. It claims 100% of one processor core. After a few minutes gschem returns to normal operation with new numbers on the copied symbols. There are no messages in the log window or on the command line.
When given the same renumber task, the autonumber diolog from the menu returns in less than a second.
---<)kaimartin(>--- |
Autonumber on paste of a copied selection is very ineffcient.
To reproduce:
1) add the following lines to gschemrc to activate autonumber on insert:
(load-from-path "auto-uref.scm")
(define auto-uref-set-page-offset 100)
(add-hook! add-component-hook auto-uref)
(add-hook! copy-component-hook auto-uref)
2) open a schematic with a decent amount of components (~100 symbols will do)
3) select the whole schematic (e.g. with [ctrl-a])
4) copy the selection to buffer (e.g. with [ctrl-c])
5) paste the buffer at some other place
result: gschem gets unresponsive. It claims 100% of one processor core. After a few minutes gschem returns to normal operation with new numbers on the copied symbols. There are no messages in the log window or on the command line.
When given the same renumber task, the autonumber diolog from the menu returns in less than a second.
---<)kaimartin(>--- |
|
