Re: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

On Fri, Oct 12, 2012 at 8:54 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 11/10/2012 12:51, Scott Kostyshak a écrit :

 Any comments on this?



 Sorry Scott, I thought it was in already. I think this patch is fine.

It's in.

Thanks a lot for all of your help on this, JMarc. You could have
implemented this yourself in a matter of minutes but instead you spent
hours helping me stumble along and learn.

Scott

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 15/10/2012 16:15, Scott Kostyshak a écrit :

Thanks a lot for all of your help on this, JMarc. You could have
implemented this yourself in a matter of minutes but instead you spent
hours helping me stumble along and learn.


Well, this was in a part of code I care about, so it felt normal to have 
a look. And actually, *you* spend hours iterating the code, I spent 
minutes commenting on it :)


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

On Fri, Oct 12, 2012 at 8:54 AM, Jean-Marc Lasgouttes
 wrote:
> Le 11/10/2012 12:51, Scott Kostyshak a écrit :
>>
>> Any comments on this?
>
>
>
> Sorry Scott, I thought it was in already. I think this patch is fine.

It's in.

Thanks a lot for all of your help on this, JMarc. You could have
implemented this yourself in a matter of minutes but instead you spent
hours helping me stumble along and learn.

Scott

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 15/10/2012 16:15, Scott Kostyshak a écrit :

Thanks a lot for all of your help on this, JMarc. You could have
implemented this yourself in a matter of minutes but instead you spent
hours helping me stumble along and learn.


Well, this was in a part of code I care about, so it felt normal to have 
a look. And actually, *you* spend hours iterating the code, I spent 
minutes commenting on it :)


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 11/10/2012 12:51, Scott Kostyshak a écrit :

Any comments on this?



Sorry Scott, I thought it was in already. I think this patch is fine.

JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 11/10/2012 12:51, Scott Kostyshak a écrit :

Any comments on this?



Sorry Scott, I thought it was in already. I think this patch is fine.

JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

On Mon, Aug 27, 2012 at 12:09 PM, Scott Kostyshak
skost...@princeton.edu wrote:
 From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
 Sent: Thursday, August 23, 2012 9:15 AM

Then I propose to simplify things a lot by only dispatching to visible
buffers (for now). No more special parameter.

 The updated patch is attached.

 How does it look?

 Scott

Any comments on this?

Thanks,

Scott

Re: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

On Mon, Aug 27, 2012 at 12:09 PM, Scott Kostyshak
 wrote:
> From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
> Sent: Thursday, August 23, 2012 9:15 AM
>
>>Then I propose to simplify things a lot by only dispatching to visible
>>buffers (for now). No more special parameter.
>
> The updated patch is attached.
>
> How does it look?
>
> Scott

Any comments on this?

Thanks,

Scott

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, August 23, 2012 9:15 AM

Then I propose to simplify things a lot by only dispatching to visible
buffers (for now). No more special parameter.

The updated patch is attached.

How does it look?

Scottdiff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index db1c82a..8e3ec77 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3148,21 +3148,22 @@ void LyXAction::init()
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
- * \li Action: Applies a command to all visible, hidden, or both types of buffers in the active window.
- * \li Syntax: buffer-forall [BUFFER-TYPE] LFUN-COMMAND
- * \li Params: BUFFER-TYPE: visible|hidden|both default: default: visible   
-   LFUN-COMMAND: The command that is to be applied to the buffers.
- * \li Sample: Close all Notes in all visible documents: \n
+ * \li Action: Applies a command to all non-hidden buffers.
+ * \li Notion: a buffer is `hidden' if it is internally opened in LyX, but not
+   visible in any window.
+ * \li Syntax: buffer-forall LFUN-COMMAND
+ * \li Params: LFUN-COMMAND: The command to be applied to the buffers.
+ * \li Sample: Close all Notes in buffers: \n
 	   buffer-forall inset-forall Note inset-toggle close \n
-   Toggle change tracking on all documents: \n
-	   buffer-forall both changes-track \n
-   Toggle read-only for all visible documents: \n
+   Toggle change tracking on buffers: \n
+	   buffer-forall changes-track \n
+   Toggle read-only for buffers: \n
 	   buffer-forall buffer-toggle-read-only \n
-   Show statistics for each document: \n
-	   buffer-forall both statistics \n
-   Activate the branch named Solutions in all visible documents: \n
+   Show statistics for individual buffers: \n
+	   buffer-forall statistics \n
+   Activate the branch named Solutions in buffers: \n
 	   buffer-forall branch-activate Solutions \n
-   Export all visible documents to PDF (pdflatex): \n
+   Export buffers to PDF (pdflatex): \n
 	   buffer-forall buffer-export pdf2 \n
  * \li Origin: scottkostyshak, 20 Jul 2012
  * \endvar
diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index c5048dd..347d403 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1092,8 +1092,15 @@ bool GuiApplication::getStatus(FuncRequest const  cmd, FuncStatus  flag) const
 		break;
 
 	case LFUN_BUFFER_FORALL: {
-		if (!currentView() || !currentView()-currentBufferView() || !currentView()-currentBufferView()-buffer()) {
-			flag.message(from_utf8(N_(Command not allowed without any visible document in the active window)));
+		if (theBufferList().empty()) {
+			flag.message(from_utf8(N_(Command not allowed without a buffer open)));
+			flag.setEnabled(false);
+			break;
+		}
+
+		FuncRequest const cmdToPass = lyxaction.lookupFunc(cmd.getLongArg(0));
+		if (cmdToPass.action() == LFUN_UNKNOWN_ACTION) {
+			flag.message(from_utf8(N_(the LFUN-COMMAND argument of buffer-forall is not valid)));
 			flag.setEnabled(false);
 		}
 		break;
@@ -1616,59 +1623,73 @@ void GuiApplication::dispatch(FuncRequest const  cmd, DispatchResult  dr)
 	}
 
 	case LFUN_BUFFER_FORALL: {
-		GuiView * gv = currentView();
-		Buffer * const buf = gv-currentBufferView()-buffer();
-
-		bool processVisible = true;
-		bool processHidden = false;
-		docstring msg = _(Applied the following command to all visible buffers in the active window: );
-		string commandToRun = argument;
-		if (cmd.getArg(0) == both) {
-			processHidden = true;
-			msg = _(Applied the following command to all visible and hidden buffers in the active window: );
-			commandToRun = cmd.getLongArg(1);
-		} else if (cmd.getArg(0) == visible) {
-			commandToRun = cmd.getLongArg(1);
-		} else if (cmd.getArg(0) == hidden) {
-			processHidden = true;
-			processVisible = false;
-			commandToRun = cmd.getLongArg(1);
-			msg = _(Applied the following command to all hidden buffers in the active window: );
-		}
-		FuncRequest const funcToRun = lyxaction.lookupFunc(commandToRun);
-		dr.setMessage(bformat(_(%1$s%2$s), msg, from_utf8(commandToRun)));
+		FuncRequest const funcToRun = lyxaction.lookupFunc(cmd.getLongArg(0));
+
+		mapBuffer *, GuiView * views_lVisible;
+		mapGuiView *, Buffer * activeBuffers;
+
+		QListGuiView * allViews = d-views_.values();
 
+		//this foreach does not modify any buffer. It just collects info on local visibility of buffers
+		//and on which buffer is active in each view.
 		Buffer * const last = theBufferList().last();
+		foreach (GuiView * view, allViews) {
+			//all of the buffers might be locally hidden. That is, there is no active buffer.
+			if (!view || !view-currentBufferView() || 

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, August 23, 2012 9:15 AM

>Then I propose to simplify things a lot by only dispatching to visible
>buffers (for now). No more special parameter.

The updated patch is attached.

How does it look?

Scottdiff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index db1c82a..8e3ec77 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3148,21 +3148,22 @@ void LyXAction::init()
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer },
 /*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
- * \li Action: Applies a command to all visible, hidden, or both types of buffers in the active window.
- * \li Syntax: buffer-forall [] 
- * \li Params: :  default: visible   
-   : The command that is to be applied to the buffers.
- * \li Sample: Close all Notes in all visible documents: \n
+ * \li Action: Applies a command to all non-hidden buffers.
+ * \li Notion: a buffer is `hidden' if it is internally opened in LyX, but not
+   visible in any window.
+ * \li Syntax: buffer-forall 
+ * \li Params: : The command to be applied to the buffers.
+ * \li Sample: Close all Notes in buffers: \n
 	   buffer-forall inset-forall Note inset-toggle close \n
-   Toggle change tracking on all documents: \n
-	   buffer-forall both changes-track \n
-   Toggle read-only for all visible documents: \n
+   Toggle change tracking on buffers: \n
+	   buffer-forall changes-track \n
+   Toggle read-only for buffers: \n
 	   buffer-forall buffer-toggle-read-only \n
-   Show statistics for each document: \n
-	   buffer-forall both statistics \n
-   Activate the branch named "Solutions" in all visible documents: \n
+   Show statistics for individual buffers: \n
+	   buffer-forall statistics \n
+   Activate the branch named "Solutions" in buffers: \n
 	   buffer-forall branch-activate Solutions \n
-   Export all visible documents to PDF (pdflatex): \n
+   Export buffers to PDF (pdflatex): \n
 	   buffer-forall buffer-export pdf2 \n
  * \li Origin: scottkostyshak, 20 Jul 2012
  * \endvar
diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index c5048dd..347d403 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1092,8 +1092,15 @@ bool GuiApplication::getStatus(FuncRequest const & cmd, FuncStatus & flag) const
 		break;
 
 	case LFUN_BUFFER_FORALL: {
-		if (!currentView() || !currentView()->currentBufferView() || !()->currentBufferView()->buffer()) {
-			flag.message(from_utf8(N_("Command not allowed without any visible document in the active window")));
+		if (theBufferList().empty()) {
+			flag.message(from_utf8(N_("Command not allowed without a buffer open")));
+			flag.setEnabled(false);
+			break;
+		}
+
+		FuncRequest const cmdToPass = lyxaction.lookupFunc(cmd.getLongArg(0));
+		if (cmdToPass.action() == LFUN_UNKNOWN_ACTION) {
+			flag.message(from_utf8(N_("the  argument of buffer-forall is not valid")));
 			flag.setEnabled(false);
 		}
 		break;
@@ -1616,59 +1623,73 @@ void GuiApplication::dispatch(FuncRequest const & cmd, DispatchResult & dr)
 	}
 
 	case LFUN_BUFFER_FORALL: {
-		GuiView * gv = currentView();
-		Buffer * const buf = >currentBufferView()->buffer();
-
-		bool processVisible = true;
-		bool processHidden = false;
-		docstring msg = _("Applied the following command to all visible buffers in the active window: ");
-		string commandToRun = argument;
-		if (cmd.getArg(0) == "both") {
-			processHidden = true;
-			msg = _("Applied the following command to all visible and hidden buffers in the active window: ");
-			commandToRun = cmd.getLongArg(1);
-		} else if (cmd.getArg(0) == "visible") {
-			commandToRun = cmd.getLongArg(1);
-		} else if (cmd.getArg(0) == "hidden") {
-			processHidden = true;
-			processVisible = false;
-			commandToRun = cmd.getLongArg(1);
-			msg = _("Applied the following command to all hidden buffers in the active window: ");
-		}
-		FuncRequest const funcToRun = lyxaction.lookupFunc(commandToRun);
-		dr.setMessage(bformat(_("%1$s%2$s"), msg, from_utf8(commandToRun)));
+		FuncRequest const funcToRun = lyxaction.lookupFunc(cmd.getLongArg(0));
+
+		map views_lVisible;
+		map activeBuffers;
+
+		QList allViews = d->views_.values();
 
+		//this foreach does not modify any buffer. It just collects info on local visibility of buffers
+		//and on which buffer is active in each view.
 		Buffer * const last = theBufferList().last();
+		foreach (GuiView * view, allViews) {
+			//all of the buffers might be locally hidden. That is, there is no active buffer.
+			if (!view || !view->currentBufferView() || !>currentBufferView()->buffer())
+activeBuffers[view] = 0;
+			else
+activeBuffers[view] = 

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 23/08/2012 06:19, Scott Kostyshak a écrit :

Currently buffer-forall rehides each hidden buffer after the LFUN is applied.
Should it not do that?


Is it because they had to be made visible earlier?

JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, August 23, 2012 4:41 AM

Le 23/08/2012 06:19, Scott Kostyshak a écrit :
 Currently buffer-forall rehides each hidden buffer after the LFUN is applied.
 Should it not do that?

Is it because they had to be made visible earlier?

I don't know how to dispatch a function to a buffer without first switching to 
it:
vLv-setBuffer(b);
lyx::dispatch(funcToRun);

Is there a better way?

Also, it seems that LyX does not like having a dirty hidden buffer so it 
prompts the user to save before re-hiding. I don't know how this would work if 
it didn't have to switch to the buffer first. I think I even saw source code 
somewhere that assumed that all hidden buffers were clean.

I'm traveling now and will send a new patch with the changes we discussed on 
Monday.

Thanks,

Scott

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 23/08/2012 06:19, Scott Kostyshak a écrit :

Currently buffer-forall rehides each hidden buffer after the LFUN is applied.
Should it not do that?


Is it because they had to be made visible earlier?

JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, August 23, 2012 4:41 AM

>Le 23/08/2012 06:19, Scott Kostyshak a écrit :
>> Currently buffer-forall rehides each hidden buffer after the LFUN is applied.
>> Should it not do that?

>Is it because they had to be made visible earlier?

I don't know how to dispatch a function to a buffer without first switching to 
it:
vLv->setBuffer(b);
lyx::dispatch(funcToRun);

Is there a better way?

Also, it seems that LyX does not like having a dirty hidden buffer so it 
prompts the user to save before re-hiding. I don't know how this would work if 
it didn't have to switch to the buffer first. I think I even saw source code 
somewhere that assumed that all hidden buffers were clean.

I'm traveling now and will send a new patch with the changes we discussed on 
Monday.

Thanks,

Scott

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Friday, July 20, 2012 4:45 AM

The problem is that the LFUN is mixing real hidden buffers (visible nowhere)
with the ones that are visible in some other window. I think these two things
are very different from a user point of view.

Conclusion: you should not ask only the current view for visibleness (?), but
all views.

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Friday, July 20, 2012 5:06 AM

* the default should be all buffers visible in a view

I agree with the above points you made. LFUN_BUFFER_FORALL now supports
multiple views and I tried to add some structure on the terms visible and
hidden, which are now defined in the LFUN documentation. The language is kind
of confusing, but I cannot think of a clearer way. I'm pasting the definitions
here for your thoughts and so that the rest of this email makes sense:

+ * \li Notion: A buffer is `locally visible' with respect to a view if it
+   is visible within that view. If not, it is `locally hidden'.
+   A buffer is `globally visible' if there exists an open view in
+   which it is locally visible. If not, it is `globally hidden'.


I decided to use the term view in the LFUN documentation. Even though I think
the term window is more familiar to users, I think view will help the new
user realize the connection of a buffer being visible if it is in a view
(similar words). Actually, if this is my argument then maybe viewable is a
better word than visible. Any thoughts?

* It may be better to force the use of the first argument, because as it is
this argument is not well defined. You could use * for all buffers, as in
inset-forall

The first argument is now required. This is also a good idea because it avoids
the problem if someone misspells the first argument. For example, if the
command were 'buffer-forall hiden self-insert hello', buffer-forall would have
treated hiden as the LFUN. The first argument is now
[lVisible|gVisible|lHidden|gHidden|*]

Note that lVisible does not make sense with no tabs (the user might as well
just run the LFUN directly). lHidden could be useful without tabs if you wanted
to run an LFUN on all buffers *except* the one you're working on.

I could have made the first argument [lVisible|gVisible|lHidden|gHidden|*]
into two arguments: [visible|hidden] [locally|globally]. I'm not sure where
* would fit in best there. Any thoughts?

* if you want to handle multiple view, I suspect that the logic of you main
loop will have to change. An alternative would be to invoke
BufferView::dispatch or even Buffer::dispatch, but this is restrictive.

The main loop did change a lot. I am a little disappointed that the code had to
get a lot more complicated, but I don't see an easier way and I think it is
worth it. I went through several iterations of different logic and ended up on
the one in the attached patch. I hope I did not fall into the feature-bloat
trap but now most sets of buffers are supported and the terms are well-defined.
I used more comments than usual because of the added complexity. Please let me
know which comments I should remove.

* if the action closes the only open buffer of the lyxview, does it crash?

'buffer-forall * buffer-close' works fine.
'buffer-forall * lyx-quit' does not (for more than one buffer open). I did not
try to address this. Should I?

I tested buffer-forall a lot with Open documents in tabs checked and 
unchecked.
I'm not sure if this is enough to know how things will work on Mac and Windows.
Should I put out an email asking for testers on lyx-devel?

Any comments on variable names, style, or general logic would be great. There
are some things that could still be added. For example, perhaps the user wants
to run the LFUN on all buffers that are visible in all windows. visible in all
windows (i.e. locally visible in all views) is not a supported set by
buffer-forall. Please let me know if you can think of additional functionality
that is missing and that should be added.

I'm sorry to take up so much of your time on this LFUN, JMarc. 

Thanks,

Scottdiff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index bf3db52..9f83b5c 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3139,22 +3139,32 @@ void LyXAction::init()
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
- * \li Action: Applies a command to all visible, hidden, or both types of buffers in the active window.
- * \li Syntax: buffer-forall [BUFFER-TYPE] LFUN-COMMAND
- * \li Params: BUFFER-TYPE: visible|hidden|both default: default: visible   
-   LFUN-COMMAND: The command that is to be applied to the buffers.
- * \li Sample: Close all Notes in all visible documents: \n
-	   buffer-forall inset-forall Note inset-toggle close \n
-   Toggle change tracking on all documents: \n
-	   buffer-forall both changes-track \n
-   

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 22/08/2012 09:04, Scott Kostyshak a écrit :

I agree with the above points you made. LFUN_BUFFER_FORALL now supports
multiple views and I tried to add some structure on the terms visible and
hidden, which are now defined in the LFUN documentation. The language is kind
of confusing, but I cannot think of a clearer way. I'm pasting the definitions
here for your thoughts and so that the rest of this email makes sense:

+ * \li Notion: A buffer is `locally visible' with respect to a view if it
+   is visible within that view. If not, it is `locally hidden'.
+   A buffer is `globally visible' if there exists an open view in
+   which it is locally visible. If not, it is `globally hidden'.


Do you really think that 'locally visible' and especially 'locally 
hidden' have real use cases, or are they just added for the sake of 
being complete? I would think that all/visible/hidden is good enough.



I decided to use the term view in the LFUN documentation. Even though I think
the term window is more familiar to users, I think view will help the new
user realize the connection of a buffer being visible if it is in a view
(similar words). Actually, if this is my argument then maybe viewable is a
better word than visible. Any thoughts?


Just use view (window) in the description, maybe?


The first argument is now required.


Good.


The first argument is now [lVisible|gVisible|lHidden|gHidden|*]


This is where the extra options have a cost. People have to understand 
the subtleties of local/global visibility to use the lfun (and the names 
are ugly :)



The main loop did change a lot. I am a little disappointed that the code had to
get a lot more complicated, but I don't see an easier way and I think it is
worth it. I went through several iterations of different logic and ended up on
the one in the attached patch. I hope I did not fall into the feature-bloat
trap but now most sets of buffers are supported and the terms are well-defined.
I used more comments than usual because of the added complexity. Please let me
know which comments I should remove.

I tested buffer-forall a lot with Open documents in tabs checked and 
unchecked.
I'm not sure if this is enough to know how things will work on Mac and Windows.
Should I put out an email asking for testers on lyx-devel?


If you tested correctly these possibilities, I think there is no need to 
worry. Since the feature does not affect people who do not us it, we 
have time to act when a bug is found.



Any comments on variable names, style, or general logic would be great.


A few comments:

* in order to make the code more readable, you could move the part that 
constructs the list of buffers to some new GuiApplication method. It 
could even be possible to create GuiView helpers if that makes the code 
easier to understand.


* concerning the complexity, I am not sure why you cannot first get a 
list ouf buffers to process (the foreach) and than process all of them 
(the while loop) without making lots of different cases.


* I am not sure it is worth having precise counting of what type of 
buffers have been processed. Only one message

  Applied \%1$s\ to %2$d buffer(s)
is almost good enough, and showing the list of files names (without 
paths) instead would be even more informative



There are some things that could still be added. For example, perhaps the user 
wants
to run the LFUN on all buffers that are visible in all windows. visible in all
windows (i.e. locally visible in all views) is not a supported set by
buffer-forall. Please let me know if you can think of additional functionality
that is missing and that should be added.


I think the biggest risk now is overengineering. My advice is to 
implement the features that you *know* you need, and wait until people 
complain that their use case is not covered. From there, you can update 
the function. For example, it might turn out that there is a need to 
filter on master/child (think export to PDF).


Trying to cover all possible uses from the start has a cost.


I'm sorry to take up so much of your time on this LFUN, JMarc.


Don't be sorry. Any patch is a good occasion to climb the learning curve 
of LyX development.


JMarc

PS: I almost forgot. Feel free to disagree with anything I wrote, of course!

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, August 22, 2012 4:12 AM

Le 22/08/2012 09:04, Scott Kostyshak a écrit :
 + * \li Notion: A buffer is `locally visible' with respect to a view if it
 +   is visible within that view. If not, it is `locally hidden'.
 +   A buffer is `globally visible' if there exists an open view 
 in
 +   which it is locally visible. If not, it is `globally hidden'.

Do you really think that 'locally visible' and especially 'locally
hidden' have real use cases, or are they just added for the sake of
being complete? I would think that all/visible/hidden is good enough.

What do you mean by visible here? Are you referring to what I am calling
globally visible?

I do think that 'locally visible' has a real use case. I could see a work-flow
where a user has some documents visible in one view (all problem sets) and some
other type of documents visible in a different view (exams). Perhaps that user
wants to apply an LFUN to all problem sets (e.g. the activate solutions
branch LFUN). This could be done by using lVisible. Of course, this work-flow
could also be achieved by using different instances of LyX instead of different
views and then just using the all or globally visible argument of
buffer-forall. Even after thinking a lot I have trouble coming up with a 
practical
use of 'locally hidden' :)

 I decided to use the term view in the LFUN documentation. Even though I 
 think
 the term window is more familiar to users, I think view will help the new
 user realize the connection of a buffer being visible if it is in a view
 (similar words). Actually, if this is my argument then maybe viewable is a
 better word than visible. Any thoughts?

Just use view (window) in the description, maybe?

I like that.

 The first argument is now [lVisible|gVisible|lHidden|gHidden|*]

This is where the extra options have a cost. People have to understand
the subtleties of local/global visibility to use the lfun (and the names
are ugly :)

Agreed on both points. Do you think that supporting all/gVisible/gHidden (which
is what I interpret your suggestion above as) would need definitions or would
the names be intuitive? I guess a buffer is visible if it is viewable in an 
open view
would be enough. I am a little hesitant to avoid using locally and globally
because otherwise the definition sounds like a buffer is visible if it is
visible in a view which is confusing and incorrect.

To make things really simple, what if only visible were supported or only
all? Do you think a user would want to apply LFUNs to only hidden documents?

 The main loop did change a lot. I am a little disappointed that the code had 
 to
 get a lot more complicated, but I don't see an easier way and I think it is
 worth it. I went through several iterations of different logic and ended up 
 on
 the one in the attached patch. I hope I did not fall into the feature-bloat
 trap but now most sets of buffers are supported and the terms are 
 well-defined.
 I used more comments than usual because of the added complexity. Please let 
 me
 know which comments I should remove.

 I tested buffer-forall a lot with Open documents in tabs checked and 
 unchecked.
 I'm not sure if this is enough to know how things will work on Mac and 
 Windows.
 Should I put out an email asking for testers on lyx-devel?

If you tested correctly these possibilities, I think there is no need to
worry. Since the feature does not affect people who do not us it, we
have time to act when a bug is found.

 Any comments on variable names, style, or general logic would be great.

A few comments:

* in order to make the code more readable, you could move the part that
constructs the list of buffers to some new GuiApplication method. It
could even be possible to create GuiView helpers if that makes the code
easier to understand.

OK, that sounds good. Once we decide on which options to support I'll see about
this.

* concerning the complexity, I am not sure why you cannot first get a
list ouf buffers to process (the foreach) and than process all of them
(the while loop) without making lots of different cases.

* I am not sure it is worth having precise counting of what type of
buffers have been processed. Only one message
   Applied \%1$s\ to %2$d buffer(s)
is almost good enough, and showing the list of files names (without
paths) instead would be even more informative

Sounds good.

I think the biggest risk now is overengineering. My advice is to
implement the features that you *know* you need, and wait until people
complain that their use case is not covered. From there, you can update
the function. For example, it might turn out that there is a need to
filter on master/child (think export to PDF).

Trying to cover all possible uses from the start has a cost.

Good advice. That's the kind of thing that I should know but that I need to be
continually reminded of. The voice of the devil on my shoulder saying more

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 22/08/2012 11:06, Scott Kostyshak a écrit :

Do you really think that 'locally visible' and especially 'locally
hidden' have real use cases, or are they just added for the sake of
being complete? I would think that all/visible/hidden is good enough.


What do you mean by visible here? Are you referring to what I am calling
globally visible?


Yes.


Agreed on both points. Do you think that supporting all/gVisible/gHidden (which
is what I interpret your suggestion above as) would need definitions or would
the names be intuitive? I guess a buffer is visible if it is viewable in an open 
view
would be enough. I am a little hesitant to avoid using locally and globally
because otherwise the definition sounds like a buffer is visible if it is
visible in a view which is confusing and incorrect.


I would  revert the definition: a buffer is hidden if it is internally 
opened in LyX, but not visible in any window (rewritten into proper 
English)



To make things really simple, what if only visible were supported or only
all? Do you think a user would want to apply LFUNs to only hidden documents?


Maybe to close them or to make them visible.


Now my first thought is to do one of the following:

(1) only support visible (globally visible)
(2) only support all
(3) support both visible and all.

I will need to think about this more. What do you think?


Maybe you should keep visible/hidden/all, if only for symmetry.

BTW, an idea for a next patch: in the document list of the View menu, 
files opened in another window appear as hidden. This is wrong of 
course. They should probably be in a different submenu other windows.


However, in the 'no tabs' mac scenario, this does not make sense at all, 
since all files should be displayed and selecting one with the view menu 
should just give focus to the proper window.


Supporting both tabs and multiple windows is a UX nightmare in my opinion.

JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, August 22, 2012 6:27 AM

I would  revert the definition: a buffer is hidden if it is internally
opened in LyX, but not visible in any window (rewritten into proper
English)

Sounds good.

 To make things really simple, what if only visible were supported or only
 all? Do you think a user would want to apply LFUNs to only hidden 
 documents?

Maybe to close them or to make them visible.

Currently buffer-forall rehides each hidden buffer after the LFUN is applied.
Should it not do that?

Maybe you should keep visible/hidden/all, if only for symmetry.

OK.

BTW, an idea for a next patch: in the document list of the View menu,
files opened in another window appear as hidden. This is wrong of
course. They should probably be in a different submenu other windows.

However, in the 'no tabs' mac scenario, this does not make sense at all,
since all files should be displayed and selecting one with the view menu
should just give focus to the proper window.

Supporting both tabs and multiple windows is a UX nightmare in my opinion.

Agreed.

Scott

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Friday, July 20, 2012 4:45 AM

>The problem is that the LFUN is mixing real hidden buffers (visible nowhere)
>with the ones that are visible in some other window. I think these two things
>are very different from a user point of view.

>Conclusion: you should not ask only the current view for visibleness (?), but
>all views.

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Friday, July 20, 2012 5:06 AM

>* the default should be "all buffers visible in a view"

I agree with the above points you made. LFUN_BUFFER_FORALL now supports
multiple views and I tried to add some structure on the terms "visible" and
"hidden", which are now defined in the LFUN documentation. The language is kind
of confusing, but I cannot think of a clearer way. I'm pasting the definitions
here for your thoughts and so that the rest of this email makes sense:

+ * \li Notion: A buffer is `locally visible' with respect to a view if it
+   is visible within that view. If not, it is `locally hidden'.
+   A buffer is `globally visible' if there exists an open view in
+   which it is locally visible. If not, it is `globally hidden'.


I decided to use the term "view" in the LFUN documentation. Even though I think
the term "window" is more familiar to users, I think "view" will help the new
user realize the connection of a buffer being "visible" if it is in a "view"
(similar words). Actually, if this is my argument then maybe "viewable" is a
better word than "visible". Any thoughts?

>* It may be better to force the use of the first argument, because as it is
>this argument is not well defined. You could use * for all buffers, as in
>inset-forall

The first argument is now required. This is also a good idea because it avoids
the problem if someone misspells the first argument. For example, if the
command were 'buffer-forall hiden self-insert hello', buffer-forall would have
treated "hiden" as the LFUN. The first argument is now
[lVisible|gVisible|lHidden|gHidden|*]

Note that lVisible does not make sense with no tabs (the user might as well
just run the LFUN directly). lHidden could be useful without tabs if you wanted
to run an LFUN on all buffers *except* the one you're working on.

I could have made the first argument [lVisible|gVisible|lHidden|gHidden|*]
into two arguments: [visible|hidden] [locally|globally]. I'm not sure where
"*" would fit in best there. Any thoughts?

>* if you want to handle multiple view, I suspect that the logic of you main
>loop will have to change. An alternative would be to invoke
>BufferView::dispatch or even Buffer::dispatch, but this is restrictive.

The main loop did change a lot. I am a little disappointed that the code had to
get a lot more complicated, but I don't see an easier way and I think it is
worth it. I went through several iterations of different logic and ended up on
the one in the attached patch. I hope I did not fall into the feature-bloat
trap but now most sets of buffers are supported and the terms are well-defined.
I used more comments than usual because of the added complexity. Please let me
know which comments I should remove.

>* if the action closes the only open buffer of the lyxview, does it crash?

'buffer-forall * buffer-close' works fine.
'buffer-forall * lyx-quit' does not (for more than one buffer open). I did not
try to address this. Should I?

I tested buffer-forall a lot with "Open documents in tabs" checked and 
unchecked.
I'm not sure if this is enough to know how things will work on Mac and Windows.
Should I put out an email asking for testers on lyx-devel?

Any comments on variable names, style, or general logic would be great. There
are some things that could still be added. For example, perhaps the user wants
to run the LFUN on all buffers that are visible in all windows. "visible in all
windows" (i.e. "locally visible" in all views) is not a supported set by
buffer-forall. Please let me know if you can think of additional functionality
that is missing and that should be added.

I'm sorry to take up so much of your time on this LFUN, JMarc. 

Thanks,

Scottdiff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index bf3db52..9f83b5c 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3139,22 +3139,32 @@ void LyXAction::init()
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer },
 /*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
- * \li Action: Applies a command to all visible, hidden, or both types of buffers in the active window.
- * \li Syntax: buffer-forall [] 
- * \li Params: :  default: visible   
-   : The command that is to be applied to the buffers.
- * \li Sample: Close all Notes in all visible documents: \n
-	   buffer-forall inset-forall Note inset-toggle close \n
-   Toggle change tracking on all documents: \n
-	   buffer-forall both changes-track \n
-  

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 22/08/2012 09:04, Scott Kostyshak a écrit :

I agree with the above points you made. LFUN_BUFFER_FORALL now supports
multiple views and I tried to add some structure on the terms "visible" and
"hidden", which are now defined in the LFUN documentation. The language is kind
of confusing, but I cannot think of a clearer way. I'm pasting the definitions
here for your thoughts and so that the rest of this email makes sense:

+ * \li Notion: A buffer is `locally visible' with respect to a view if it
+   is visible within that view. If not, it is `locally hidden'.
+   A buffer is `globally visible' if there exists an open view in
+   which it is locally visible. If not, it is `globally hidden'.


Do you really think that 'locally visible' and especially 'locally 
hidden' have real use cases, or are they just added for the sake of 
being complete? I would think that all/visible/hidden is good enough.



I decided to use the term "view" in the LFUN documentation. Even though I think
the term "window" is more familiar to users, I think "view" will help the new
user realize the connection of a buffer being "visible" if it is in a "view"
(similar words). Actually, if this is my argument then maybe "viewable" is a
better word than "visible". Any thoughts?


Just use "view (window)" in the description, maybe?


The first argument is now required.


Good.


The first argument is now [lVisible|gVisible|lHidden|gHidden|*]


This is where the extra options have a cost. People have to understand 
the subtleties of local/global visibility to use the lfun (and the names 
are ugly :)



The main loop did change a lot. I am a little disappointed that the code had to
get a lot more complicated, but I don't see an easier way and I think it is
worth it. I went through several iterations of different logic and ended up on
the one in the attached patch. I hope I did not fall into the feature-bloat
trap but now most sets of buffers are supported and the terms are well-defined.
I used more comments than usual because of the added complexity. Please let me
know which comments I should remove.

I tested buffer-forall a lot with "Open documents in tabs" checked and 
unchecked.
I'm not sure if this is enough to know how things will work on Mac and Windows.
Should I put out an email asking for testers on lyx-devel?


If you tested correctly these possibilities, I think there is no need to 
worry. Since the feature does not affect people who do not us it, we 
have time to act when a bug is found.



Any comments on variable names, style, or general logic would be great.


A few comments:

* in order to make the code more readable, you could move the part that 
constructs the list of buffers to some new GuiApplication method. It 
could even be possible to create GuiView helpers if that makes the code 
easier to understand.


* concerning the complexity, I am not sure why you cannot first get a 
list ouf buffers to process (the foreach) and than process all of them 
(the while loop) without making lots of different cases.


* I am not sure it is worth having precise counting of what type of 
buffers have been processed. Only one message

  "Applied \"%1$s\" to %2$d buffer(s)"
is almost good enough, and showing the list of files names (without 
paths) instead would be even more informative



There are some things that could still be added. For example, perhaps the user 
wants
to run the LFUN on all buffers that are visible in all windows. "visible in all
windows" (i.e. "locally visible" in all views) is not a supported set by
buffer-forall. Please let me know if you can think of additional functionality
that is missing and that should be added.


I think the biggest risk now is overengineering. My advice is to 
implement the features that you *know* you need, and wait until people 
complain that their use case is not covered. From there, you can update 
the function. For example, it might turn out that there is a need to 
filter on master/child (think export to PDF).


Trying to cover all possible uses from the start has a cost.


I'm sorry to take up so much of your time on this LFUN, JMarc.


Don't be sorry. Any patch is a good occasion to climb the learning curve 
of LyX development.


JMarc

PS: I almost forgot. Feel free to disagree with anything I wrote, of course!

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, August 22, 2012 4:12 AM

>Le 22/08/2012 09:04, Scott Kostyshak a écrit :
>> + * \li Notion: A buffer is `locally visible' with respect to a view if it
>> +   is visible within that view. If not, it is `locally hidden'.
>> +   A buffer is `globally visible' if there exists an open view 
>> in
>> +   which it is locally visible. If not, it is `globally hidden'.
>
>Do you really think that 'locally visible' and especially 'locally
>hidden' have real use cases, or are they just added for the sake of
>being complete? I would think that all/visible/hidden is good enough.

What do you mean by "visible" here? Are you referring to what I am calling
"globally visible"?

I do think that 'locally visible' has a real use case. I could see a work-flow
where a user has some documents visible in one view (all problem sets) and some
other type of documents visible in a different view (exams). Perhaps that user
wants to apply an LFUN to all problem sets (e.g. the "activate solutions
branch" LFUN). This could be done by using lVisible. Of course, this work-flow
could also be achieved by using different instances of LyX instead of different
views and then just using the "all" or "globally visible" argument of
buffer-forall. Even after thinking a lot I have trouble coming up with a 
practical
use of 'locally hidden' :)

>> I decided to use the term "view" in the LFUN documentation. Even though I 
>> think
>> the term "window" is more familiar to users, I think "view" will help the new
>> user realize the connection of a buffer being "visible" if it is in a "view"
>> (similar words). Actually, if this is my argument then maybe "viewable" is a
>> better word than "visible". Any thoughts?
>
>Just use "view (window)" in the description, maybe?

I like that.

>> The first argument is now [lVisible|gVisible|lHidden|gHidden|*]
>
>This is where the extra options have a cost. People have to understand
>the subtleties of local/global visibility to use the lfun (and the names
>are ugly :)

Agreed on both points. Do you think that supporting all/gVisible/gHidden (which
is what I interpret your suggestion above as) would need definitions or would
the names be intuitive? I guess "a buffer is visible if it is viewable in an 
open view"
would be enough. I am a little hesitant to avoid using "locally" and "globally"
because otherwise the definition sounds like "a buffer is visible if it is
visible in a view" which is confusing and incorrect.

To make things really simple, what if only "visible" were supported or only
"all"? Do you think a user would want to apply LFUNs to only hidden documents?

>> The main loop did change a lot. I am a little disappointed that the code had 
>> to
>> get a lot more complicated, but I don't see an easier way and I think it is
>> worth it. I went through several iterations of different logic and ended up 
>> on
>> the one in the attached patch. I hope I did not fall into the feature-bloat
>> trap but now most sets of buffers are supported and the terms are 
>> well-defined.
>> I used more comments than usual because of the added complexity. Please let 
>> me
>> know which comments I should remove.
>>
>> I tested buffer-forall a lot with "Open documents in tabs" checked and 
>> unchecked.
>> I'm not sure if this is enough to know how things will work on Mac and 
>> Windows.
>> Should I put out an email asking for testers on lyx-devel?
>
>If you tested correctly these possibilities, I think there is no need to
>worry. Since the feature does not affect people who do not us it, we
>have time to act when a bug is found.
>
>> Any comments on variable names, style, or general logic would be great.
>
>A few comments:
>
>* in order to make the code more readable, you could move the part that
>constructs the list of buffers to some new GuiApplication method. It
>could even be possible to create GuiView helpers if that makes the code
>easier to understand.

OK, that sounds good. Once we decide on which options to support I'll see about
this.

>* concerning the complexity, I am not sure why you cannot first get a
>list ouf buffers to process (the foreach) and than process all of them
>(the while loop) without making lots of different cases.

>* I am not sure it is worth having precise counting of what type of
>buffers have been processed. Only one message
>   "Applied \"%1$s\" to %2$d buffer(s)"
>is almost good enough, and showing the list of files names (without
>paths) instead would be even more informative

Sounds good.

>I think the biggest risk now is overengineering. My advice is to
>implement the features that you *know* you need, and wait until people
>complain that their use case is not covered. From there, you can update
>the function. For example, it might turn out that there is a need to
>filter on master/child (think export to PDF).
>
>Trying to cover all possible uses from the start has a cost.

Good advice. 

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 22/08/2012 11:06, Scott Kostyshak a écrit :

Do you really think that 'locally visible' and especially 'locally
hidden' have real use cases, or are they just added for the sake of
being complete? I would think that all/visible/hidden is good enough.


What do you mean by "visible" here? Are you referring to what I am calling
"globally visible"?


Yes.


Agreed on both points. Do you think that supporting all/gVisible/gHidden (which
is what I interpret your suggestion above as) would need definitions or would
the names be intuitive? I guess "a buffer is visible if it is viewable in an open 
view"
would be enough. I am a little hesitant to avoid using "locally" and "globally"
because otherwise the definition sounds like "a buffer is visible if it is
visible in a view" which is confusing and incorrect.


I would  revert the definition: "a buffer is hidden if it is internally 
opened in LyX, but not visible in any window" (rewritten into proper 
English)



To make things really simple, what if only "visible" were supported or only
"all"? Do you think a user would want to apply LFUNs to only hidden documents?


Maybe to close them or to make them visible.


Now my first thought is to do one of the following:

(1) only support "visible" (globally visible)
(2) only support "all"
(3) support both "visible" and "all".

I will need to think about this more. What do you think?


Maybe you should keep visible/hidden/all, if only for symmetry.

BTW, an idea for a next patch: in the document list of the View menu, 
files opened in another window appear as hidden. This is wrong of 
course. They should probably be in a different submenu "other windows".


However, in the 'no tabs' mac scenario, this does not make sense at all, 
since all files should be displayed and selecting one with the view menu 
should just give focus to the proper window.


Supporting both tabs and multiple windows is a UX nightmare in my opinion.

JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, August 22, 2012 6:27 AM

>I would  revert the definition: "a buffer is hidden if it is internally
>opened in LyX, but not visible in any window" (rewritten into proper
>English)

Sounds good.

>> To make things really simple, what if only "visible" were supported or only
>> "all"? Do you think a user would want to apply LFUNs to only hidden 
>> documents?

>Maybe to close them or to make them visible.

Currently buffer-forall rehides each hidden buffer after the LFUN is applied.
Should it not do that?

>Maybe you should keep visible/hidden/all, if only for symmetry.

OK.

>BTW, an idea for a next patch: in the document list of the View menu,
>files opened in another window appear as hidden. This is wrong of
>course. They should probably be in a different submenu "other windows".

>However, in the 'no tabs' mac scenario, this does not make sense at all,
>since all files should be displayed and selecting one with the view menu
>should just give focus to the proper window.

>Supporting both tabs and multiple windows is a UX nightmare in my opinion.

Agreed.

Scott

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, July 19, 2012 4:15 AM

Le 19/07/2012 04:46, Scott Kostyshak a écrit :
 If there are more windows open, buffer-forall iterates over the
 buffers in the current window, treating a buffer as hidden as
 designated in the current window.

It would be nice to rephrase the status message to reflect the situation
like maybe
Applied the following command to all visible buffers in this window: 
(or something else, I am not the native english speaker here)

That sounds good. I put the active window instead of this window because 
(at least in Linux) if you have messages open on a window, open a new window, 
and execute a command in the mini-buffer of the new window, the message box of 
the old window will show that command and its output. Thus, the this would 
refer to the incorrect window. Attached is the updated patch.

Note however that on the Mac tabs are not used by default and that each
files is in its own window (there is an option for that). buffer-forall
is just useless in this case, isn't it?

Interesting, I didn't know this. The Open Documents in Tabs is not checked by 
default for Macs? I wonder how it is on Windows and what other settings are 
different across platforms. Where does this happen in the source code?

You are right that buffer-forall doesn't do anything useful by default. 
However, when you create a new window the buffers in the previous window are 
available as hidden buffers in the new window. Thus, buffer-forall both 
LFUN-COMMAND would be useful because it iterates over the hidden buffers (as 
defined in the active window) as well. My feeling now is that we should have 
both as the default instead of visible. What do you think?

This could lead to behavior that is a little strange, such as if you run 
`buffer-forall both statistics` with multiple windows open. You will see tabs 
appear. However, I think that's a special case.

Thanks,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..a1cf57f 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120720
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..7a4ec33 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,28 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers in the active window.
+ * \li Syntax: buffer-forall [BUFFER-TYPE] LFUN-COMMAND
+ * \li Params: BUFFER-TYPE: visible|hidden|both default: default: visible   
+   LFUN-COMMAND: The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	   buffer-forall both statistics \n
+   Activate the branch named Solutions in all visible documents: \n
+	   buffer-forall branch-activate Solutions \n
+   Export all visible documents to PDF (pdflatex): \n
+	   buffer-forall buffer-export pdf2 \n
+ * \li Origin: scottkostyshak, 20 Jul 2012
+ * \endvar
+ */
+		{ LFUN_BUFFER_FORALL, buffer-forall, ReadOnly | Argument, Buffer },
+/*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_WRITE_ALL
  * \li Action: Save all changed documents.
  * \li Syntax: buffer-write-all
diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index b855067..94581a3 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -38,6 +38,7 @@
 #include Font.h
 #include FuncRequest.h
 #include FuncStatus.h
+#include GuiWorkArea.h
 #include Intl.h
 #include KeyMap.h
 #include Language.h
@@ -1077,6 +1078,15 @@ bool GuiApplication::getStatus(FuncRequest const  cmd, FuncStatus  flag) const
 		enable = true;
 		break;
 
+	case LFUN_BUFFER_FORALL: {
+		if (!currentView() || !currentView()-currentBufferView() || !currentView()-currentBufferView()-buffer()) {
+			flag.message(from_utf8(N_(Command not allowed without any visible document in the active window)));
+			flag.setEnabled(false);
+		}
+		break;
+	}
+
+
 	default:
 		return false;
 	}
@@ -1592,6 +1602,63 @@ void GuiApplication::dispatch(FuncRequest const  cmd, DispatchResult  dr)
 		break;
 	}
 
+	case LFUN_BUFFER_FORALL: {
+		GuiView * gv = currentView();
+		Buffer * const buf = 

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 20/07/2012 08:12, Scott Kostyshak a écrit :

That sounds good. I put the active window instead of this window
because (at least in Linux) if you have messages open on a window,
open a new window, and execute a command in the mini-buffer of the
new window, the message box of the old window will show that command
and its output. Thus, the this would refer to the incorrect window.
Attached is the updated patch.


Very good. I'll commit that.


Interesting, I didn't know this. The Open Documents in Tabs is not
checked by default for Macs? I wonder how it is on Windows and what
other settings are different across platforms. Where does this happen
in the source code?


Nowhere :) We use a file lyxrc.dist that can be changed by the packager 
to initialize some setting. On the mac it is created from

development/MacOSX/lyxrc.dist.in


You are right that buffer-forall doesn't do anything useful by
default. However, when you create a new window the buffers in the
previous window are available as hidden buffers in the new window.


The problem is that the LFUN is mixing real hidden buffers (visible 
nowhere) with the ones that are visible in some other window. I think 
these two things are very different from a user point of view.


Conclusion: you should not ask only the current view for visibleness 
(?), but all views.


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 20/07/2012 10:45, Jean-Marc Lasgouttes a écrit :

You are right that buffer-forall doesn't do anything useful by
default. However, when you create a new window the buffers in the
previous window are available as hidden buffers in the new window.


The problem is that the LFUN is mixing real hidden buffers (visible
nowhere) with the ones that are visible in some other window. I think
these two things are very different from a user point of view.

Conclusion: you should not ask only the current view for visibleness
(?), but all views.


I have pushed the patch to master now. Thanks for te patch (and for 
going through all the iterations).


I pushed the patch now because I will go in vacation this evening and 
did not want to let it in a limbo, but I think you should think again 
about multiple views.


* the default should be all buffers visible in a view

* It may be better to force the use of the first argument, because as it 
is this argument is not well defined. You could use * for all buffers, 
as in inset-forall


* if the action closes the only open buffer of the lyxview, does it crash?

* if you want to handle multiple view, I suspect that the logic of you 
main loop will have to change. An alternative would be to invoke 
BufferView::dispatch or even Buffer::dispatch, but this is restrictive.


JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, July 19, 2012 4:15 AM

>Le 19/07/2012 04:46, Scott Kostyshak a écrit :
>> If there are more windows open, buffer-forall iterates over the
>> buffers in the current window, treating a buffer as hidden as
>> designated in the current window.

>It would be nice to rephrase the status message to reflect the situation
>like maybe
>"Applied the following command to all visible buffers in this window: "
>(or something else, I am not the native english speaker here)

That sounds good. I put "the active window" instead of "this window" because 
(at least in Linux) if you have messages open on a window, open a new window, 
and execute a command in the mini-buffer of the new window, the message box of 
the old window will show that command and its output. Thus, the "this" would 
refer to the incorrect window. Attached is the updated patch.

>Note however that on the Mac tabs are not used by default and that each
>files is in its own window (there is an option for that). buffer-forall
>is just useless in this case, isn't it?

Interesting, I didn't know this. The "Open Documents in Tabs" is not checked by 
default for Macs? I wonder how it is on Windows and what other settings are 
different across platforms. Where does this happen in the source code?

You are right that buffer-forall doesn't do anything useful by default. 
However, when you create a new window the buffers in the previous window are 
available as hidden buffers in the new window. Thus, buffer-forall both 
 would be useful because it iterates over the hidden buffers (as 
defined in the active window) as well. My feeling now is that we should have 
"both" as the default instead of "visible". What do you think?

This could lead to behavior that is a little strange, such as if you run 
`buffer-forall both statistics` with multiple windows open. You will see tabs 
appear. However, I think that's a special case.

Thanks,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..a1cf57f 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120720
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..7a4ec33 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,28 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers in the active window.
+ * \li Syntax: buffer-forall [] 
+ * \li Params: :  default: visible   
+   : The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	   buffer-forall both statistics \n
+   Activate the branch named "Solutions" in all visible documents: \n
+	   buffer-forall branch-activate Solutions \n
+   Export all visible documents to PDF (pdflatex): \n
+	   buffer-forall buffer-export pdf2 \n
+ * \li Origin: scottkostyshak, 20 Jul 2012
+ * \endvar
+ */
+		{ LFUN_BUFFER_FORALL, "buffer-forall", ReadOnly | Argument, Buffer },
+/*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_WRITE_ALL
  * \li Action: Save all changed documents.
  * \li Syntax: buffer-write-all
diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index b855067..94581a3 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -38,6 +38,7 @@
 #include "Font.h"
 #include "FuncRequest.h"
 #include "FuncStatus.h"
+#include "GuiWorkArea.h"
 #include "Intl.h"
 #include "KeyMap.h"
 #include "Language.h"
@@ -1077,6 +1078,15 @@ bool GuiApplication::getStatus(FuncRequest const & cmd, FuncStatus & flag) const
 		enable = true;
 		break;
 
+	case LFUN_BUFFER_FORALL: {
+		if (!currentView() || !currentView()->currentBufferView() || !()->currentBufferView()->buffer()) {
+			flag.message(from_utf8(N_("Command not allowed without any visible document in the active window")));
+			flag.setEnabled(false);
+		}
+		break;
+	}
+
+
 	default:
 		return false;
 	}
@@ -1592,6 +1602,63 @@ void GuiApplication::dispatch(FuncRequest const & cmd, DispatchResult & dr)
 		break;
 	}
 
+	case LFUN_BUFFER_FORALL: {
+		GuiView * gv = currentView();
+		Buffer * const buf = >currentBufferView()->buffer();
+
+		bool 

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 20/07/2012 08:12, Scott Kostyshak a écrit :

That sounds good. I put "the active window" instead of "this window"
because (at least in Linux) if you have messages open on a window,
open a new window, and execute a command in the mini-buffer of the
new window, the message box of the old window will show that command
and its output. Thus, the "this" would refer to the incorrect window.
Attached is the updated patch.


Very good. I'll commit that.


Interesting, I didn't know this. The "Open Documents in Tabs" is not
checked by default for Macs? I wonder how it is on Windows and what
other settings are different across platforms. Where does this happen
in the source code?


Nowhere :) We use a file lyxrc.dist that can be changed by the packager 
to initialize some setting. On the mac it is created from

development/MacOSX/lyxrc.dist.in


You are right that buffer-forall doesn't do anything useful by
default. However, when you create a new window the buffers in the
previous window are available as hidden buffers in the new window.


The problem is that the LFUN is mixing real hidden buffers (visible 
nowhere) with the ones that are visible in some other window. I think 
these two things are very different from a user point of view.


Conclusion: you should not ask only the current view for visibleness 
(?), but all views.


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 20/07/2012 10:45, Jean-Marc Lasgouttes a écrit :

You are right that buffer-forall doesn't do anything useful by
default. However, when you create a new window the buffers in the
previous window are available as hidden buffers in the new window.


The problem is that the LFUN is mixing real hidden buffers (visible
nowhere) with the ones that are visible in some other window. I think
these two things are very different from a user point of view.

Conclusion: you should not ask only the current view for visibleness
(?), but all views.


I have pushed the patch to master now. Thanks for te patch (and for 
going through all the iterations).


I pushed the patch now because I will go in vacation this evening and 
did not want to let it in a limbo, but I think you should think again 
about multiple views.


* the default should be "all buffers visible in a view"

* It may be better to force the use of the first argument, because as it 
is this argument is not well defined. You could use * for all buffers, 
as in inset-forall


* if the action closes the only open buffer of the lyxview, does it crash?

* if you want to handle multiple view, I suspect that the logic of you 
main loop will have to change. An alternative would be to invoke 
BufferView::dispatch or even Buffer::dispatch, but this is restrictive.


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 19/07/2012 04:46, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org] Sent: Wednesday, July
18, 2012 4:14 AM

JMarc,

Thank you for your guidance. Attached is an updated patch and below I
respond to your comments.


Great! Just one thing beofre committing:


BTW, what happens if several windows are open? It looks like you
are not going to see whether the buffers on other windows are


If there are more windows open, buffer-forall iterates over the
buffers in the current window, treating a buffer as hidden as
designated in the current window.


It would be nice to rephrase the status message to reflect the situation 
like maybe

Applied the following command to all visible buffers in this window: 
(or something else, I am not the native english speaker here)

Note however that on the Mac tabs are not used by default and that each 
files is in its own window (there is an option for that). buffer-forall 
is just useless in this case, isn't it?


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 19/07/2012 04:46, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org] Sent: Wednesday, July
18, 2012 4:14 AM

JMarc,

Thank you for your guidance. Attached is an updated patch and below I
respond to your comments.


Great! Just one thing beofre committing:


BTW, what happens if several windows are open? It looks like you
are not going to see whether the buffers on other windows are


If there are more windows open, buffer-forall iterates over the
buffers in the current window, treating a buffer as hidden as
designated in the current window.


It would be nice to rephrase the status message to reflect the situation 
like maybe

"Applied the following command to all visible buffers in this window: "
(or something else, I am not the native english speaker here)

Note however that on the Mac tabs are not used by default and that each 
files is in its own window (there is an option for that). buffer-forall 
is just useless in this case, isn't it?


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 18/07/2012 06:39, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM


Moreover, this code should not be in GuiView, but in
GuiApplication, since the function is at application level.

Attached is my attempt to move the code to GuiApplication. I am having trouble 
instantiating a GuiWorkArea. Here are the errors I get:

GuiApplication.cpp: In member function ‘virtual void 
lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest, 
lyx::DispatchResult)’:
GuiApplication.cpp:1633:8: error: invalid use of incomplete type ‘class 
lyx::frontend::GuiWorkArea’
In file included from GuiApplication.cpp:15:0:
GuiApplication.h:41:7: error: forward declaration of ‘class 
lyx::frontend::GuiWorkArea’


Try to #include GuiWorkArea.h at the start of GuiApplication.cpp.


I think that this patch also addresses the other points you raised.


It begins to look very good. See below for comments.

JMarc


+   case LFUN_BUFFER_FORALL: {
+   GuiView * cv = currentView();


What if currentView() is null? I propose to do an early return in this 
case. Or maybe this can happen when all buffers are hidden and requires 
finer codeing. I do not know whether this is only a theoretical 
possibility, this may happen when using client to do scripting. On the 
mac at least, LyX can be running witout having any open window.


Unless you want to be very complete, it is probably enough right now to 
return early.


I do not think I have seen cv used as the name of a GuiView. From a 
quick poll if the source, I suggest gv or view. The good thing about 
using a known name is that it requires less effort for the reader of the 
code.



+   Buffer * const buf = cv-currentBufferView()-buffer();


Do we have a bufferview when the LyX window is there but no buffer is open?


+   FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);


FuncRequest const funcToRun =...
(constify and no capitalization of variable names)


+   dr.setMessage(bformat(_(%1$s%2$s), msg, 
from_utf8(commandToRun)));



+   Buffer * const last = theBufferList().last();
+   Buffer * b = theBufferList().first();
+   Buffer * nextBuf = 0;
+   // We cannot use a for loop as the buffer list cycles.
+   while (true) {
+   if (b != last)
+   nextBuf = theBufferList().next(b); //get next 
now bc LFUN might close current
+
+   bool const hidden = !(guiApp-currentView()  
guiApp-currentView()-workArea(*b));


No need to use guiApp- there. Are you using currentView() because cv 
could become invalid? If so, why do you use it below?


BTW, what happens if several windows are open? It looks like you are not 
going to see whether the buffers on other windows are



+   if (hidden) {
+   if (processHidden) {
+   cv-setBuffer(b);
+   lyx::dispatch(FuncToRun);
+   GuiWorkArea * const wa = 
cv-currentWorkArea();
+   wa-view().hideWorkArea(wa);


I am not sure that the intermediate wa variable is useful here.


+   }
+   }
+
+   else {
+   if (processVisible) {


else if (processvisible) { ...

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, July 18, 2012 4:14 AM

JMarc,

Thank you for your guidance. Attached is an updated patch and below I respond 
to your comments.

Scott

Try to #include GuiWorkArea.h at the start of GuiApplication.cpp.

That works.

 + case LFUN_BUFFER_FORALL: {
 + GuiView * cv = currentView();

What if currentView() is null? I propose to do an early return in this
case. Or maybe this can happen when all buffers are hidden and requires
finer codeing. I do not know whether this is only a theoretical
possibility, this may happen when using client to do scripting. On the
mac at least, LyX can be running witout having any open window.

Unless you want to be very complete, it is probably enough right now to
return early.

I wouldn't mind trying to address this if you think that would be better. For 
now I don't allow for this situation by disabling the function in getStatus. I 
didn't realize that it's possible to have a hidden window without a visible 
window. The current patch disables the function in this situation. I don't know 
how to check for the existence of a hidden buffer without a visible buffer.

I do not think I have seen cv used as the name of a GuiView. From a
quick poll if the source, I suggest gv or view. The good thing about
using a known name is that it requires less effort for the reader of the
code.

Done.

 + Buffer * const buf = cv-currentBufferView()-buffer();

Do we have a bufferview when the LyX window is there but no buffer is open?

I put in some checks.

 + FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);

FuncRequest const funcToRun =...
(constify and no capitalization of variable names)

Done.

 + dr.setMessage(bformat(_(%1$s%2$s), msg, 
 from_utf8(commandToRun)));

 + Buffer * const last = theBufferList().last();
 + Buffer * b = theBufferList().first();
 + Buffer * nextBuf = 0;
 + // We cannot use a for loop as the buffer list cycles.
 + while (true) {
 + if (b != last)
 + nextBuf = theBufferList().next(b); //get next 
 now bc LFUN might close current
 +
 + bool const hidden = !(guiApp-currentView()  
 guiApp-currentView()-workArea(*b));

No need to use guiApp- there. Are you using currentView() because cv
could become invalid? If so, why do you use it below?

Done.

BTW, what happens if several windows are open? It looks like you are not
going to see whether the buffers on other windows are

If there are more windows open, buffer-forall iterates over the buffers in the 
current window, treating a buffer as hidden as designated in the current 
window. When a new window is opened it treats all of the open buffers as 
hidden. The default of buffer-forall of not iterating over hidden buffers is 
thus nice in the case that a user doesn't know what a hidden buffer is or 
doesn't know that the buffers in the other windows would be affected by 
buffer-forall because they are automatically available as hidden.

 + if (hidden) {
 + if (processHidden) {
 + cv-setBuffer(b);
 + lyx::dispatch(FuncToRun);
 + GuiWorkArea * const wa = 
 cv-currentWorkArea();
 + wa-view().hideWorkArea(wa);

I am not sure that the intermediate wa variable is useful here.

Done.diff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..872721a 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120718
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..3767e31 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,28 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers in the current window.
+ * \li Syntax: buffer-forall [BUFFER-TYPE] LFUN-COMMAND
+ * \li Params: BUFFER-TYPE: visible|hidden|both default: default: visible   
+   LFUN-COMMAND: The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 18/07/2012 06:39, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM


>Moreover, this code should not be in GuiView, but in
>GuiApplication, since the function is at application level.

Attached is my attempt to move the code to GuiApplication. I am having trouble 
instantiating a GuiWorkArea. Here are the errors I get:

GuiApplication.cpp: In member function ‘virtual void 
lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest&, 
lyx::DispatchResult&)’:
GuiApplication.cpp:1633:8: error: invalid use of incomplete type ‘class 
lyx::frontend::GuiWorkArea’
In file included from GuiApplication.cpp:15:0:
GuiApplication.h:41:7: error: forward declaration of ‘class 
lyx::frontend::GuiWorkArea’


Try to #include "GuiWorkArea.h" at the start of GuiApplication.cpp.


I think that this patch also addresses the other points you raised.


It begins to look very good. See below for comments.

JMarc


+   case LFUN_BUFFER_FORALL: {
+   GuiView * cv = currentView();


What if currentView() is null? I propose to do an early return in this 
case. Or maybe this can happen when all buffers are hidden and requires 
finer codeing. I do not know whether this is only a theoretical 
possibility, this may happen when using client to do scripting. On the 
mac at least, LyX can be running witout having any open window.


Unless you want to be very complete, it is probably enough right now to 
return early.


I do not think I have seen "cv" used as the name of a GuiView. From a 
quick poll if the source, I suggest "gv" or "view". The good thing about 
using a known name is that it requires less effort for the reader of the 
code.



+   Buffer * const buf = >currentBufferView()->buffer();


Do we have a bufferview when the LyX window is there but no buffer is open?


+   FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);


FuncRequest const funcToRun =...
(constify and no capitalization of variable names)


+   dr.setMessage(bformat(_("%1$s%2$s"), msg, 
from_utf8(commandToRun)));



+   Buffer * const last = theBufferList().last();
+   Buffer * b = theBufferList().first();
+   Buffer * nextBuf = 0;
+   // We cannot use a for loop as the buffer list cycles.
+   while (true) {
+   if (b != last)
+   nextBuf = theBufferList().next(b); //get next 
now bc LFUN might close current
+
+   bool const hidden = !(guiApp->currentView() && 
guiApp->currentView()->workArea(*b));


No need to use guiApp-> there. Are you using currentView() because cv 
could become invalid? If so, why do you use it below?


BTW, what happens if several windows are open? It looks like you are not 
going to see whether the buffers on other windows are



+   if (hidden) {
+   if (processHidden) {
+   cv->setBuffer(b);
+   lyx::dispatch(FuncToRun);
+   GuiWorkArea * const wa = 
cv->currentWorkArea();
+   wa->view().hideWorkArea(wa);


I am not sure that the intermediate wa variable is useful here.


+   }
+   }
+
+   else {
+   if (processVisible) {


else if (processvisible) { ...

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, July 18, 2012 4:14 AM

JMarc,

Thank you for your guidance. Attached is an updated patch and below I respond 
to your comments.

Scott

>Try to #include "GuiWorkArea.h" at the start of GuiApplication.cpp.

That works.

>> + case LFUN_BUFFER_FORALL: {
>> + GuiView * cv = currentView();

>What if currentView() is null? I propose to do an early return in this
>case. Or maybe this can happen when all buffers are hidden and requires
>finer codeing. I do not know whether this is only a theoretical
>possibility, this may happen when using client to do scripting. On the
>mac at least, LyX can be running witout having any open window.

>Unless you want to be very complete, it is probably enough right now to
>return early.

I wouldn't mind trying to address this if you think that would be better. For 
now I don't allow for this situation by disabling the function in getStatus. I 
didn't realize that it's possible to have a hidden window without a visible 
window. The current patch disables the function in this situation. I don't know 
how to check for the existence of a hidden buffer without a visible buffer.

>I do not think I have seen "cv" used as the name of a GuiView. From a
>quick poll if the source, I suggest "gv" or "view". The good thing about
>using a known name is that it requires less effort for the reader of the
>code.

Done.

>> + Buffer * const buf = >currentBufferView()->buffer();

>Do we have a bufferview when the LyX window is there but no buffer is open?

I put in some checks.

>> + FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);

>FuncRequest const funcToRun =...
>(constify and no capitalization of variable names)

Done.

>> + dr.setMessage(bformat(_("%1$s%2$s"), msg, 
>> from_utf8(commandToRun)));

>> + Buffer * const last = theBufferList().last();
>> + Buffer * b = theBufferList().first();
>> + Buffer * nextBuf = 0;
>> + // We cannot use a for loop as the buffer list cycles.
>> + while (true) {
>> + if (b != last)
>> + nextBuf = theBufferList().next(b); //get next 
>> now bc LFUN might close current
>> +
>> + bool const hidden = !(guiApp->currentView() && 
>> guiApp->currentView()->workArea(*b));

>No need to use guiApp-> there. Are you using currentView() because cv
>could become invalid? If so, why do you use it below?

Done.

>BTW, what happens if several windows are open? It looks like you are not
>going to see whether the buffers on other windows are

If there are more windows open, buffer-forall iterates over the buffers in the 
current window, treating a buffer as hidden as designated in the current 
window. When a new window is opened it treats all of the open buffers as 
hidden. The default of buffer-forall of not iterating over hidden buffers is 
thus nice in the case that a user doesn't know what a hidden buffer is or 
doesn't know that the buffers in the other windows would be affected by 
buffer-forall because they are automatically available as hidden.

>> + if (hidden) {
>> + if (processHidden) {
>> + cv->setBuffer(b);
>> + lyx::dispatch(FuncToRun);
>> + GuiWorkArea * const wa = 
>> cv->currentWorkArea();
>> + wa->view().hideWorkArea(wa);

>I am not sure that the intermediate wa variable is useful here.

Done.diff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..872721a 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120718
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..3767e31 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,28 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers in the current window.
+ * \li Syntax: buffer-forall [] 
+ * \li Params: :  default: visible   
+   : The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM

Moreover, this code should not be in GuiView, but in
GuiApplication, since the function is at application level.

Attached is my attempt to move the code to GuiApplication. I am having trouble 
instantiating a GuiWorkArea. Here are the errors I get:

GuiApplication.cpp: In member function ‘virtual void 
lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest, 
lyx::DispatchResult)’:
GuiApplication.cpp:1633:8: error: invalid use of incomplete type ‘class 
lyx::frontend::GuiWorkArea’
In file included from GuiApplication.cpp:15:0:
GuiApplication.h:41:7: error: forward declaration of ‘class 
lyx::frontend::GuiWorkArea’

I think that this patch also addresses the other points you raised.

Thanks,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..2c99432 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..ff3f7fe 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,26 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers.
+ * \li Syntax: buffer-forall [BUFFER-TYPE] LFUN-COMMAND
+ * \li Params: BUFFER-TYPE: visible|hidden|both default: default: visible   
+   LFUN-COMMAND: The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	   buffer-forall both statistics \n
+   Activate the branch named Solutions in all visible documents: \n
+	   buffer-forall branch-activate Solutions \n
+ * \li Origin: scottkostyshak, 15 Jul 2012
+ * \endvar
+ */
+		{ LFUN_BUFFER_FORALL, buffer-forall, ReadOnly | Argument, Buffer },
+/*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_WRITE_ALL
  * \li Action: Save all changed documents.
  * \li Syntax: buffer-write-all
diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index b855067..fe37b81 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1074,6 +1074,7 @@ bool GuiApplication::getStatus(FuncRequest const  cmd, FuncStatus  flag) const
 	case LFUN_RECONFIGURE:
 	case LFUN_SERVER_GET_FILENAME:
 	case LFUN_SERVER_NOTIFY:
+	case LFUN_BUFFER_FORALL:
 		enable = true;
 		break;
 
@@ -1592,6 +1593,64 @@ void GuiApplication::dispatch(FuncRequest const  cmd, DispatchResult  dr)
 		break;
 	}
 
+	case LFUN_BUFFER_FORALL: {
+		GuiView * cv = currentView();
+		Buffer * const buf = cv-currentBufferView()-buffer();
+
+		bool processVisible = true;
+		bool processHidden = false;
+		docstring msg = _(Applied the following command to all visible buffers: );
+		string commandToRun = argument;
+		if (cmd.getArg(0) == both) {
+			processHidden = true;
+			msg = _(Applied the following command to all visible and hidden buffers: );
+			commandToRun = cmd.getLongArg(1);
+		} else if (cmd.getArg(0) == visible) {
+			commandToRun = cmd.getLongArg(1);
+		} else if (cmd.getArg(0) == hidden) {
+			processHidden = true;
+			processVisible = false;
+			commandToRun = cmd.getLongArg(1);
+			msg = _(Applied the following command to all hidden buffers: );
+		}
+		FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);
+		dr.setMessage(bformat(_(%1$s%2$s), msg, from_utf8(commandToRun)));
+
+		Buffer * const last = theBufferList().last();
+		Buffer * b = theBufferList().first();
+		Buffer * nextBuf = 0;
+		// We cannot use a for loop as the buffer list cycles.
+		while (true) {
+			if (b != last)
+nextBuf = theBufferList().next(b); //get next now bc LFUN might close current 
+
+			bool const hidden = !(guiApp-currentView()  guiApp-currentView()-workArea(*b));
+			if (hidden) {
+if (processHidden) {
+	cv-setBuffer(b);
+	lyx::dispatch(FuncToRun);
+	GuiWorkArea * const wa = cv-currentWorkArea();
+	wa-view().hideWorkArea(wa);
+}
+			}
+
+			else {
+if (processVisible) {
+	cv-setBuffer(b);
+	lyx::dispatch(FuncToRun);
+}
+			}
+
+			if (b == last)
+break;
+			b = nextBuf;
+		}
+
+		if (theBufferList().isLoaded(buf)) //the LFUN might have closed buf
+			cv-setBuffer(buf);
+		break;
+	}
+
 	case LFUN_COMMAND_ALTERNATIVES: {
 		// 

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM

>Moreover, this code should not be in GuiView, but in
>GuiApplication, since the function is at application level.

Attached is my attempt to move the code to GuiApplication. I am having trouble 
instantiating a GuiWorkArea. Here are the errors I get:

GuiApplication.cpp: In member function ‘virtual void 
lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest&, 
lyx::DispatchResult&)’:
GuiApplication.cpp:1633:8: error: invalid use of incomplete type ‘class 
lyx::frontend::GuiWorkArea’
In file included from GuiApplication.cpp:15:0:
GuiApplication.h:41:7: error: forward declaration of ‘class 
lyx::frontend::GuiWorkArea’

I think that this patch also addresses the other points you raised.

Thanks,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..2c99432 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..ff3f7fe 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,26 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers.
+ * \li Syntax: buffer-forall [] 
+ * \li Params: :  default: visible   
+   : The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	   buffer-forall both statistics \n
+   Activate the branch named "Solutions" in all visible documents: \n
+	   buffer-forall branch-activate Solutions \n
+ * \li Origin: scottkostyshak, 15 Jul 2012
+ * \endvar
+ */
+		{ LFUN_BUFFER_FORALL, "buffer-forall", ReadOnly | Argument, Buffer },
+/*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_WRITE_ALL
  * \li Action: Save all changed documents.
  * \li Syntax: buffer-write-all
diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index b855067..fe37b81 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1074,6 +1074,7 @@ bool GuiApplication::getStatus(FuncRequest const & cmd, FuncStatus & flag) const
 	case LFUN_RECONFIGURE:
 	case LFUN_SERVER_GET_FILENAME:
 	case LFUN_SERVER_NOTIFY:
+	case LFUN_BUFFER_FORALL:
 		enable = true;
 		break;
 
@@ -1592,6 +1593,64 @@ void GuiApplication::dispatch(FuncRequest const & cmd, DispatchResult & dr)
 		break;
 	}
 
+	case LFUN_BUFFER_FORALL: {
+		GuiView * cv = currentView();
+		Buffer * const buf = >currentBufferView()->buffer();
+
+		bool processVisible = true;
+		bool processHidden = false;
+		docstring msg = _("Applied the following command to all visible buffers: ");
+		string commandToRun = argument;
+		if (cmd.getArg(0) == "both") {
+			processHidden = true;
+			msg = _("Applied the following command to all visible and hidden buffers: ");
+			commandToRun = cmd.getLongArg(1);
+		} else if (cmd.getArg(0) == "visible") {
+			commandToRun = cmd.getLongArg(1);
+		} else if (cmd.getArg(0) == "hidden") {
+			processHidden = true;
+			processVisible = false;
+			commandToRun = cmd.getLongArg(1);
+			msg = _("Applied the following command to all hidden buffers: ");
+		}
+		FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);
+		dr.setMessage(bformat(_("%1$s%2$s"), msg, from_utf8(commandToRun)));
+
+		Buffer * const last = theBufferList().last();
+		Buffer * b = theBufferList().first();
+		Buffer * nextBuf = 0;
+		// We cannot use a for loop as the buffer list cycles.
+		while (true) {
+			if (b != last)
+nextBuf = theBufferList().next(b); //get next now bc LFUN might close current 
+
+			bool const hidden = !(guiApp->currentView() && guiApp->currentView()->workArea(*b));
+			if (hidden) {
+if (processHidden) {
+	cv->setBuffer(b);
+	lyx::dispatch(FuncToRun);
+	GuiWorkArea * const wa = cv->currentWorkArea();
+	wa->view().hideWorkArea(wa);
+}
+			}
+
+			else {
+if (processVisible) {
+	cv->setBuffer(b);
+	lyx::dispatch(FuncToRun);
+}
+			}
+
+			if (b == last)
+break;
+			b = nextBuf;
+		}
+
+		if (theBufferList().isLoaded(buf)) //the LFUN might have closed buf
+			cv->setBuffer(buf);
+		break;
+	}
+
 	case LFUN_COMMAND_ALTERNATIVES: {
 		// 

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 15/07/12 22:35, Scott Kostyshak a écrit :

Attached is a patch that implements LFUN_BUFFER_FORALL, which applies a
passed LFUN command to all buffers. My motivation was that I sometimes
need to do the same thing in all of the buffers that I have open.
Another advantage of implementing this LFUN is that it allows
buffer-specific settings to be made global. For example, if a user wants
to be able to toggle track changes for all documents, he can do that
(similarly for read only).


This looks like a useful feature.


When a buffer-forall command is issued and the command passed to it is
disabled on one of the buffers, currently buffer-forall continues on to
the other buffers and tries to execute the passed command. I think this
is the correct behavior. Alternatively, buffer-forall could stop
whenever it finds a buffer where the command is disabled.


You current choice looks good.


buffer-forall allows for an optional flag, includehidden. If
includehidden is not specified, hidden buffers are ignored. If
includehidden is specified, the action is applied to the hidden buffers
and then they are hidden again. I might extend this option to allow for
onlyhidden, which would not apply the command to non-hidden buffers.
This would allow, e.g., to close all hidden buffers.



Any comments?


See below in the patch.

JMarc

+   case LFUN_BUFFER_FORALL: {
+   Buffer * const buf = currentBufferView()-buffer();
+   if (!buf)
+   break;


Why is this test needed? The current buffer has nothing to do with 
buffer-forall. Moreover, this code should not be in GuiView, but in 
GuiApplication, since the function is at application level.



+
+   bool processHidden = false;
+   string commandToRun = argument;
+   if (argument.substr(0,13) == includehidden) {
+   processHidden = true;
+   commandToRun = argument.substr(14, 
argument.size());
+   }


Please do not use string methods by hand. FuncRequest object have 
methods getArg and getLongArg that work very well for these uses.



+
+   docstring const hiddenOrNot = processHidden ? _(all hidden and 
non-hidden) : _(all non-hidden);
+   dr.setMessage(bformat(_(Applied the command \%1$s\ to 
%2$s buffers), from_utf8(commandToRun), hiddenOrNot));


Please use two complete sentences (one for hidden and one for not 
hidden). Your sentences may be difficult to translate in some languages.



+
+   Buffer * const last = theBufferList().last();
+   Buffer * b = theBufferList().first();
+   Buffer * nextBuf = 0;
+   // We cannot use a for loop as the buffer list cycles.


I know this code is taken from somewhere else, but I am not sure why you 
can't use BufferList::begin()/end(). The only problem is maybe what 
happens if the buffer is deleted by the lfun.



+   while (true) {
+   if (b != last)
+   nextBuf = theBufferList().next(b); 
//get next now bc LFUN might close current
+
+   bool const hidden = !(guiApp-currentView()  
guiApp-currentView()-workArea(*b));
+   if (hidden) {
+   if (processHidden) {
+   setBuffer(b);
+   
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
+   GuiWorkArea * const wa = 
currentWorkArea();
+   wa-view().hideWorkArea(wa);
+   }
+   }
+
+   else {
+   setBuffer(b);
+   
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
+   }


if (!hidden || processHidden) {
setBuffer(b);
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
if (hidden) {
GuiWorkArea * const wa = currentWorkArea();
wa-view().hideWorkArea(wa);
}
}

The lookup of commandToRun should be done at the place where the 
arguments are parsed.

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM

 + case LFUN_BUFFER_FORALL: {
 + Buffer * const buf = currentBufferView()-buffer();
 + if (!buf)
 + break;

Why is this test needed? The current buffer has nothing to do with
buffer-forall.

I use buf when I switch back to the current buffer after buffer-forall is done, 
assuming the current buffer still exists (that is, that the LFUN did not close 
it). The check is to make sure there is at least a buffer open, but as long as 
there is a check induced because of not having the NoBuffer property, I can 
take this out.

Moreover, this code should not be in GuiView, but in
GuiApplication, since the function is at application level.

ok, I will move it after the other issues are cleared up.

 +
 + bool processHidden = false;
 + string commandToRun = argument;
 + if (argument.substr(0,13) == includehidden) {
 + processHidden = true;
 + commandToRun = argument.substr(14, 
 argument.size());
 + }

 Please do not use string methods by hand. FuncRequest object have
 methods getArg and getLongArg that work very well for these uses.

Done.

 +
 + docstring const hiddenOrNot = processHidden ? _(all 
 hidden and non-hidden) : _(all non-hidden);
 + dr.setMessage(bformat(_(Applied the command \%1$s\ 
 to %2$s buffers), from_utf8(commandToRun), hiddenOrNot));

Please use two complete sentences (one for hidden and one for not
hidden). Your sentences may be difficult to translate in some languages.

Done. It is three sentences now because I am allowing three options: visible 
(default), hidden, and both.

 +
 + Buffer * const last = theBufferList().last();
 + Buffer * b = theBufferList().first();
 + Buffer * nextBuf = 0;
 + // We cannot use a for loop as the buffer list cycles.

I know this code is taken from somewhere else, but I am not sure why you
can't use BufferList::begin()/end(). The only problem is maybe what
happens if the buffer is deleted by the lfun.

Right, with BufferList::begin()/end() I don't think buffer-forall would work 
with LFUNs such as buffer-close. Should I still do it with 
BufferList::begin()/end() and blacklist certain functions? Or just let the user 
be responsible? In the attached patch I did not change it to use 
BufferList::begin()/end().


 + while (true) {
 + if (b != last)
 + nextBuf = theBufferList().next(b); 
 //get next now bc LFUN might close current
 +
 + bool const hidden = !(guiApp-currentView()  
 guiApp-currentView()-workArea(*b));
 + if (hidden) {
 + if (processHidden) {
 + setBuffer(b);
 + 
 lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
 + GuiWorkArea * const wa = 
 currentWorkArea();
 + wa-view().hideWorkArea(wa);
 + }
 + }
 +
 + else {
 + setBuffer(b);
 + 
 lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
 + }

The lookup of commandToRun should be done at the place where the
arguments are parsed.

Done.

Please see the attached patch.

Thank you for your help,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..2c99432 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..ff3f7fe 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,26 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers.
+ * \li Syntax: buffer-forall [BUFFER-TYPE] LFUN-COMMAND
+ * \li Params: BUFFER-TYPE: visible|hidden|both default: default: visible   
+   LFUN-COMMAND: The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change 

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 15/07/12 22:35, Scott Kostyshak a écrit :

Attached is a patch that implements LFUN_BUFFER_FORALL, which applies a
passed LFUN command to all buffers. My motivation was that I sometimes
need to do the same thing in all of the buffers that I have open.
Another advantage of implementing this LFUN is that it allows
buffer-specific settings to be made global. For example, if a user wants
to be able to toggle track changes for all documents, he can do that
(similarly for read only).


This looks like a useful feature.


When a buffer-forall command is issued and the command passed to it is
disabled on one of the buffers, currently buffer-forall continues on to
the other buffers and tries to execute the passed command. I think this
is the correct behavior. Alternatively, buffer-forall could stop
whenever it finds a buffer where the command is disabled.


You current choice looks good.


buffer-forall allows for an optional flag, includehidden. If
includehidden is not specified, hidden buffers are ignored. If
includehidden is specified, the action is applied to the hidden buffers
and then they are hidden again. I might extend this option to allow for
onlyhidden, which would not apply the command to non-hidden buffers.
This would allow, e.g., to close all hidden buffers.



Any comments?


See below in the patch.

JMarc

+   case LFUN_BUFFER_FORALL: {
+   Buffer * const buf = ()->buffer();
+   if (!buf)
+   break;


Why is this test needed? The current buffer has nothing to do with 
buffer-forall. Moreover, this code should not be in GuiView, but in 
GuiApplication, since the function is at application level.



+
+   bool processHidden = false;
+   string commandToRun = argument;
+   if (argument.substr(0,13) == "includehidden") {
+   processHidden = true;
+   commandToRun = argument.substr(14, 
argument.size());
+   }


Please do not use string methods by hand. FuncRequest object have 
methods getArg and getLongArg that work very well for these uses.



+
+   docstring const hiddenOrNot = processHidden ? _("all hidden and 
non-hidden") : _("all non-hidden");
+   dr.setMessage(bformat(_("Applied the command \"%1$s\" to 
%2$s buffers"), from_utf8(commandToRun), hiddenOrNot));


Please use two complete sentences (one for hidden and one for not 
hidden). Your sentences may be difficult to translate in some languages.



+
+   Buffer * const last = theBufferList().last();
+   Buffer * b = theBufferList().first();
+   Buffer * nextBuf = 0;
+   // We cannot use a for loop as the buffer list cycles.


I know this code is taken from somewhere else, but I am not sure why you 
can't use BufferList::begin()/end(). The only problem is maybe what 
happens if the buffer is deleted by the lfun.



+   while (true) {
+   if (b != last)
+   nextBuf = theBufferList().next(b); 
//get next now bc LFUN might close current
+
+   bool const hidden = !(guiApp->currentView() && 
guiApp->currentView()->workArea(*b));
+   if (hidden) {
+   if (processHidden) {
+   setBuffer(b);
+   
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
+   GuiWorkArea * const wa = 
currentWorkArea();
+   wa->view().hideWorkArea(wa);
+   }
+   }
+
+   else {
+   setBuffer(b);
+   
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
+   }


if (!hidden || processHidden) {
setBuffer(b);
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
if (hidden) {
GuiWorkArea * const wa = currentWorkArea();
wa->view().hideWorkArea(wa);
}
}

The lookup of commandToRun should be done at the place where the 
arguments are parsed.

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM

>> + case LFUN_BUFFER_FORALL: {
>> + Buffer * const buf = ()->buffer();
>> + if (!buf)
>> + break;

>Why is this test needed? The current buffer has nothing to do with
>buffer-forall.

I use buf when I switch back to the current buffer after buffer-forall is done, 
assuming the current buffer still exists (that is, that the LFUN did not close 
it). The check is to make sure there is at least a buffer open, but as long as 
there is a check induced because of not having the NoBuffer property, I can 
take this out.

>Moreover, this code should not be in GuiView, but in
>GuiApplication, since the function is at application level.

ok, I will move it after the other issues are cleared up.

>> +
>> + bool processHidden = false;
>> + string commandToRun = argument;
>> + if (argument.substr(0,13) == "includehidden") {
>> + processHidden = true;
>> + commandToRun = argument.substr(14, 
>> argument.size());
>> + }

> Please do not use string methods by hand. FuncRequest object have
> methods getArg and getLongArg that work very well for these uses.

Done.

>> +
>> + docstring const hiddenOrNot = processHidden ? _("all 
>> hidden and non-hidden") : _("all non-hidden");
>> + dr.setMessage(bformat(_("Applied the command \"%1$s\" 
>> to %2$s buffers"), from_utf8(commandToRun), hiddenOrNot));

>Please use two complete sentences (one for hidden and one for not
>hidden). Your sentences may be difficult to translate in some languages.

Done. It is three sentences now because I am allowing three options: "visible" 
(default), "hidden", and "both".

>> +
>> + Buffer * const last = theBufferList().last();
>> + Buffer * b = theBufferList().first();
>> + Buffer * nextBuf = 0;
>> + // We cannot use a for loop as the buffer list cycles.

>I know this code is taken from somewhere else, but I am not sure why you
>can't use BufferList::begin()/end(). The only problem is maybe what
>happens if the buffer is deleted by the lfun.

Right, with BufferList::begin()/end() I don't think buffer-forall would work 
with LFUNs such as buffer-close. Should I still do it with 
BufferList::begin()/end() and blacklist certain functions? Or just let the user 
be responsible? In the attached patch I did not change it to use 
BufferList::begin()/end().


>> + while (true) {
>> + if (b != last)
>> + nextBuf = theBufferList().next(b); 
>> //get next now bc LFUN might close current
>> +
>> + bool const hidden = !(guiApp->currentView() && 
>> guiApp->currentView()->workArea(*b));
>> + if (hidden) {
>> + if (processHidden) {
>> + setBuffer(b);
>> + 
>> lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
>> + GuiWorkArea * const wa = 
>> currentWorkArea();
>> + wa->view().hideWorkArea(wa);
>> + }
>> + }
>> +
>> + else {
>> + setBuffer(b);
>> + 
>> lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
>> + }

>The lookup of commandToRun should be done at the place where the
>arguments are parsed.

Done.

Please see the attached patch.

Thank you for your help,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..2c99432 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..ff3f7fe 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,26 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers.
+ * \li Syntax: buffer-forall [] 
+ * \li Params: :  default: visible   
+   : The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall