Discussion:
[PATCH] Add LFUN_SERVER_GET_STATISTICS command
Jean-Marc Lasgouttes
2014-10-15 11:46:55 UTC
Permalink
Hi,

There has been quite a bit of discussion on lyx-fr on the possibility of
reading the statistics of a document for further processing. As a
result, Stéphane Mourey implemented a new LFUN, server-get-statistics.
If there is no objection, I am going to push this to master (and
eventually branch) soon.

This patch contains an updated LFUNs.py which is obtained by doing "make
lfundoc". Would it make sense, since this requires negligible time, to
have the LFUNs.lyx file updated automatically whenever LyXAction.cpp
changes?

JMarc
Richard Heck
2014-10-15 21:12:53 UTC
Permalink
Post by Jean-Marc Lasgouttes
Hi,
There has been quite a bit of discussion on lyx-fr on the possibility
of reading the statistics of a document for further processing. As a
result, Stéphane Mourey implemented a new LFUN,
server-get-statistics. If there is no objection, I am going to push
this to master (and eventually branch) soon.
Fine with me, for both.
Post by Jean-Marc Lasgouttes
This patch contains an updated LFUNs.py which is obtained by doing
"make lfundoc". Would it make sense, since this requires negligible
time, to have the LFUNs.lyx file updated automatically whenever
LyXAction.cpp changes?
Sure.

rh
Pavel Sanda
2014-10-17 02:09:01 UTC
Permalink
Post by Jean-Marc Lasgouttes
Hi,
There has been quite a bit of discussion on lyx-fr on the possibility of
reading the statistics of a document for further processing. As a result,
Stéphane Mourey implemented a new LFUN, server-get-statistics. If there is
no objection, I am going to push this to master (and eventually branch)
soon.
What usecase lead to this lfun? If the point is to store this info in document
more proper way would be insetinfo.

Pavel
Jean-Marc Lasgouttes
2014-10-17 07:57:53 UTC
Permalink
Post by Pavel Sanda
Post by Jean-Marc Lasgouttes
Hi,
There has been quite a bit of discussion on lyx-fr on the possibility of
reading the statistics of a document for further processing. As a result,
Stéphane Mourey implemented a new LFUN, server-get-statistics. If there is
no objection, I am going to push this to master (and eventually branch)
soon.
What usecase lead to this lfun? If the point is to store this info in document
more proper way would be insetinfo.
The problem with insetinfo is that havbing to update this information at
every keystroke can be expensive, unless of course the value is not
shown in the edit window (but then you know that this is the next thing
people would ask for...).

OTOH, it would make sense to have an InsetInfo instance that shows the
result of an lfun (probably maked as Embedable in LyXAction.cpp to avoid
problems).

I guess one problem is that Stéphane did not really know what InsetInfo
was (they are not really discoverable) and thus started in this
direction. And I did not want to hamper his creativity :)

Stéphane, would you care to elaborate why a LFUN is better than an inset
that contains this same information?

JMarc
Stéphane Mourey
2014-10-17 12:55:07 UTC
Permalink
Post by Jean-Marc Lasgouttes
Post by Pavel Sanda
Post by Jean-Marc Lasgouttes
Hi,
There has been quite a bit of discussion on lyx-fr on the
possibility of
reading the statistics of a document for further processing. As a result,
Stéphane Mourey implemented a new LFUN, server-get-statistics. If there is
no objection, I am going to push this to master (and eventually branch)
soon.
What usecase lead to this lfun? If the point is to store this info in document
more proper way would be insetinfo.
The problem with insetinfo is that havbing to update this information
at every keystroke can be expensive, unless of course the value is not
shown in the edit window (but then you know that this is the next
thing people would ask for...).
OTOH, it would make sense to have an InsetInfo instance that shows the
result of an lfun (probably maked as Embedable in LyXAction.cpp to
avoid problems).
I guess one problem is that Stéphane did not really know what
InsetInfo was (they are not really discoverable) and thus started in
this direction. And I did not want to hamper his creativity :)
Stéphane, would you care to elaborate why a LFUN is better than an
inset that contains this same information?
JMarc
Well, it's hard for me to explain why lfun is better than insetinfo in
this case because I do not really know what infosets are, except the few
words Jean-Marc told me.

The fact is that, wondering what infosets are and reading the
documentation in the hope to find out, I discovered lfun and lyxserver.
So I figured out a way to get the statistics in my doc using a strategy,
mimic of the one I used previously with wordcount based on write18. And
it is fine for me. And more than that, as my documents often contain
informations that are not really part of the main text like licence or
contact informations, I was able to set modifiers to the statistics
fixing the difference in the document, but maybe could this be achieved
with insetinfo too?

I do not really know if using insetinfo better or proper, and I don't
care. I like LyX very much, not for itself, but for the way I use it.
When I read the code, I find it beautiful, with high quality standards,
and I respect that more than I can tell. So I did the trick I need this
way. It was only a few lines but they were not easy for me, as it is
only the second time in my whole life that I write some C++. Now I share
it as I'm proud of my work and I think someone else could find it useful.
I could consider to re-do it another way if I'm convicted that it is
useful to someone, but certainly not for conceptual beauty only, even if
I appreciated.

Conclusion : in this case, in my opinion, LFUN is better because the
trick is done, and insetinfo is to do. But you may consider this to be a
bad reason.

Stéphane
--
Blog: Impossible Exil <http://impossible-exil.info>
Alfredo Braunstein
2014-10-17 13:20:09 UTC
Permalink
On Fri, Oct 17, 2014 at 9:57 AM, Jean-Marc Lasgouttes
Post by Pavel Sanda
What usecase lead to this lfun? If the point is to store this info in document
more proper way would be insetinfo.
Sorry for the dumb question, but what is InsetInfo good for (in terms
of usecase). It seems like a very strange concept IMHO. Why can't it
be e.g a dialog or a panel?

A/
Pavel Sanda
2014-10-17 16:14:30 UTC
Permalink
Post by Alfredo Braunstein
Sorry for the dumb question, but what is InsetInfo good for (in terms
of usecase). It seems like a very strange concept IMHO. Why can't it
be e.g a dialog or a panel?
It's part of the document and it will be printed, so dialog won't work.
Originally for shortcuts, nowadays it can contain filename, path,
revision info.

Pavel
Alfredo Braunstein
2014-10-17 16:56:20 UTC
Permalink
I see. IMO the LFUN way is preferable. I'll give one use case where I
would find this useful: when writing a document with length
constraints (e.g. # words, # chars), it would be nice to have the
information accessible through a shortcut on the status bar (instead
of going to where the inset was inserted). Something sligthy more
human-friendly would be nicer (e.g. words: ## chars: ## chars+spaces:
##) instead of ## ## ## as in the patch.

Btw, it would be also nice to have selection-bound statistics (e.g. in
some journals / grant calls there are rigid bounds for each section or
part).

A/
Post by Pavel Sanda
Post by Alfredo Braunstein
Sorry for the dumb question, but what is InsetInfo good for (in terms
of usecase). It seems like a very strange concept IMHO. Why can't it
be e.g a dialog or a panel?
It's part of the document and it will be printed, so dialog won't work.
Originally for shortcuts, nowadays it can contain filename, path,
revision info.
Pavel
Alfredo Braunstein
2014-10-17 16:58:27 UTC
Permalink
Post by Alfredo Braunstein
I see. IMO the LFUN way is preferable. I'll give one use case where I
would find this useful: when writing a document with length
constraints (e.g. # words, # chars), it would be nice to have the
information accessible through a shortcut on the status bar (instead
of going to where the inset was inserted).
[Or firing up the statistics dialog, that is]

A/
Pavel Sanda
2014-10-17 19:23:12 UTC
Permalink
Post by Alfredo Braunstein
Btw, it would be also nice to have selection-bound statistics (e.g. in
some journals / grant calls there are rigid bounds for each section or
part).
IIRC statistics dialog will give you selection-count already. P
Alfredo Braunstein
2014-10-17 20:02:22 UTC
Permalink
Just tested and you're right.

A/
Post by Pavel Sanda
Post by Alfredo Braunstein
Btw, it would be also nice to have selection-bound statistics (e.g. in
some journals / grant calls there are rigid bounds for each section or
part).
IIRC statistics dialog will give you selection-count already. P
Jürgen Spitzmüller
2014-10-18 13:03:24 UTC
Permalink
Post by Alfredo Braunstein
I see. IMO the LFUN way is preferable. I'll give one use case where I
would find this useful: when writing a document with length
constraints (e.g. # words, # chars), it would be nice to have the
information accessible through a shortcut on the status bar (instead
of going to where the inset was inserted). Something sligthy more
##) instead of ## ## ## as in the patch.
OTOH LyX's statistic data is unusable (if not misleading) for such tasks in
many cases anyway, since it does not account for macro expansion, bibtex-
generated bibliography etc.

Since I often have to consider length constraints in papers, I have set up an
external statistics tool that is placed into a "PDF (Statistics)" converter
chain and counts words/chars in the produced pdf file instead. Using kdialog
from KDE, it pops up a dialog with more accurate statistic numbers. But of
course, this tool is strictly limited to my own needs.

Jürgen
Alfredo Braunstein
2014-10-18 20:15:01 UTC
Permalink
It's a nice idea, thanks. I once tried something like this for my own
use, but I gave up because the precise counting is picky and journal
dependent, e.g. for aps journals:
http://journals.aps.org/authors/length-guide-faq
They want the footnotes, but don't want the bibliography nor figures
and equations, that are counted separately with their own measure...
Post by Jürgen Spitzmüller
Post by Alfredo Braunstein
I see. IMO the LFUN way is preferable. I'll give one use case where I
would find this useful: when writing a document with length
constraints (e.g. # words, # chars), it would be nice to have the
information accessible through a shortcut on the status bar (instead
of going to where the inset was inserted). Something sligthy more
##) instead of ## ## ## as in the patch.
OTOH LyX's statistic data is unusable (if not misleading) for such tasks in
many cases anyway, since it does not account for macro expansion, bibtex-
generated bibliography etc.
Since I often have to consider length constraints in papers, I have set up an
external statistics tool that is placed into a "PDF (Statistics)" converter
chain and counts words/chars in the produced pdf file instead. Using kdialog
from KDE, it pops up a dialog with more accurate statistic numbers. But of
course, this tool is strictly limited to my own needs.
Jürgen
Jean-Marc Lasgouttes
2014-10-19 14:16:22 UTC
Permalink
Post by Alfredo Braunstein
I see. IMO the LFUN way is preferable. I'll give one use case where I
would find this useful: when writing a document with length
constraints (e.g. # words, # chars), it would be nice to have the
information accessible through a shortcut on the status bar (instead
of going to where the inset was inserted). Something sligthy more
##) instead of ## ## ## as in the patch.
We can extend the function to display in a human-friendly manner when
bound to a key, a toolbar icon or a menu entry.

Shall I push first what we have?

JMarc
Alfredo Braunstein
2014-10-19 14:57:52 UTC
Permalink
On Sun, Oct 19, 2014 at 4:16 PM, Jean-Marc Lasgouttes
Post by Alfredo Braunstein
I see. IMO the LFUN way is preferable. I'll give one use case where I
would find this useful: when writing a document with length
constraints (e.g. # words, # chars), it would be nice to have the
information accessible through a shortcut on the status bar (instead
of going to where the inset was inserted). Something sligthy more
##) instead of ## ## ## as in the patch.
We can extend the function to display in a human-friendly manner when bound
to a key, a toolbar icon or a menu entry.
Shall I push first what we have?
Sure.

A/

Pavel Sanda
2014-10-17 16:16:39 UTC
Permalink
Post by Jean-Marc Lasgouttes
The problem with insetinfo is that havbing to update this information at
every keystroke can be expensive, unless of course the value is not shown
in the edit window (but then you know that this is the next thing people
would ask for...).
Bummer indeed.
Post by Jean-Marc Lasgouttes
OTOH, it would make sense to have an InsetInfo instance that shows the
result of an lfun (probably maked as Embedable in LyXAction.cpp to avoid
problems).
Plus time when it needs to be updated.

Pavel
Loading...