Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Geert Janssens]

Hi John,

Op maandag 6 december 2021 20:26:39 CET schreef john:
> Geert,
> 
> This is hilarious. In that post Mr. Braam says that he maintains his
> Megapixels project on SourceHut. Follow the link. Right at the top it says
> "The development and maintainership of Megapixels has been moved to
> gitlab.com/postmarketos/megapixels
> "! That aside, the workflow
> promoted there depends on hosting at SourceHut; it's (not Free or even open
> source AFAICT) software is what provides the patch tracker.
> 
Hilarious indeed. Again I didn't follow through very deeply and missed plenty 
of these 
inconsistencies.



> 
> I'm a little puzzled by your complaint about git am saving you context
> switches. Have you tried `git pull --no-ff https://github.com/user/gnucash/
>  pr-branch`? You can copy and paste the
> line (minus the --no-ff) directly from the Github Conversation tab after
> clicking the "command line instructions" link (don't follow the
> instructions, most of the steps are unnecessary). If you prefer to do that
> in a local branch then be sure to change the merge commit message to say
> "into maint" so that you can ff-merge the local branch into maint.
> 
Even after years of using it, clearly I missed that hint. So yes that point is 
equally moot in 
my discourse.

> While searching for software to track mailing list patch submissions I found
> this: https://lwn.net/Articles/860607/ ,
> "Pulling GitHub into the kernel process". It's an interesting discussion of
> lots of alternatives that the kernel teams are considering.
> https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html
>  is
> another interesting post that mentions
> https://github.com/getpatchwork/patchwork
>  for tracking patch status from
> a mailing list. I found only one other, https://github.com/lu-zero/plaid
> , which says it's a patchwork derivative.

I'll read this discussion later. Thanks for the pointers.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[john]

> On Dec 6, 2021, at 11:02 AM, Frank H. Ellenberger 
>  wrote:
> 
> …and the bug report is?

https://bugs.gnucash.org/show_bug.cgi?id=798382 


Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[john]

Geert,

This is hilarious. In that post Mr. Braam says that he maintains his Megapixels 
project on SourceHut. Follow the link. Right at the top it says "The 
development and maintainership of Megapixels has been moved to 
gitlab.com/postmarketos/megapixels 
"! That aside, the workflow promoted 
there depends on hosting at SourceHut; it's (not Free or even open source 
AFAICT) software is what provides the patch tracker.

I do agree with him about the merge button, though, and don't use it even on 
those projects where the Github/Gitlab repo is the canonical one and it would 
work. I nearly always want to do a local check before I make a merge public, 
especially since both the author and CI built and tested the *unmerged* commits.

I'm a little puzzled by your complaint about git am saving you context 
switches. Have you tried `git pull --no-ff https://github.com/user/gnucash/ 
 pr-branch`? You can copy and paste the line 
(minus the --no-ff) directly from the Github Conversation tab after clicking 
the "command line instructions" link (don't follow the instructions, most of 
the steps are unnecessary). If you prefer to do that in a local branch then be 
sure to change the merge commit message to say "into maint" so that you can 
ff-merge the local branch into maint.

While searching for software to track mailing list patch submissions I found 
this: https://lwn.net/Articles/860607/ , 
"Pulling GitHub into the kernel process". It's an interesting discussion of 
lots of alternatives that the kernel teams are considering. 
https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html 
 is another 
interesting post that mentions https://github.com/getpatchwork/patchwork 
 for tracking patch status from a 
mailing list. I found only one other, https://github.com/lu-zero/plaid 
, which says it's a patchwork derivative.

Regards,
John Ralls


> On Dec 6, 2021, at 8:20 AM, Geert Janssens  wrote:
> 
> Well, it wasn't just Kevin's patch submission by mail that triggered my 
> reaction.
> 
> I recently also read this blog post
> https://blog.brixit.nl/git-email-flow-versus-github-flow/ 
> 
> Though as it didn't really apply to gnucash directly I only read it 
> superficially back then. Rereading it more closely I gather the git mail 
> process can be made more attractive by adding a web-based tool that displays 
> mailing list messages in a way optimized for typical git mail conversations.
> I'll also note the author apparently is allergic to merge commits which we 
> are not so his heavy focus on that argument is a little weak.
> 
> I'm not really interested in promoting such an approach. It did trigger an 
> academic curiosity towards it though as it seems to have it's own distinct 
> advantages and drawbacks.
> 
> I'll elaborate on what I perceive just for the sake of provoking thoughts.
> 
> For example, the author refers to github's merge facility (which is in his 
> opinion subpar as it generates merge commits). We can't actually use that as 
> we have declared our repos on code to be the master repos. Yet as I'm usually 
> working on the command line to steer git, using git am to apply mail patches 
> would save me a number of context switches.
> From a user point of view that same command line efficiency is possible with 
> git mail. In addition not everyone wants to have an account on github for 
> various reasons, but I presume those same people are willing to send mails 
> directly to the project.
> 
> Specifically to your first objection (large complex patches needing much 
> discussion). I didn't suggest to make it the only or even the primary channel 
> to submit patches. We could still request a formal PR on github if the patch 
> becomes too complex or rely on the suggested web-based tool to make that 
> process easier for us.
> 
> Clearly there are also downsides. Firstly there is the maintenance of yet 
> another website. Additionally much of the benefit of direct mail workflow is 
> gone if you still have to visit a website to be able to follow the review 
> conversation...
> 
> And with that I'll step down from my soapbox :)
> I do not plan to pursue this further myself as I don't think there's enough 
> net benefit for gnucash.
> 
> Regards,
> 
> Geert
> 
> Op zondag 5 december 2021 23:17:41 CET schreef John Ralls:
> > Geert,
> >
> > Reviewing and commenting a big patch with several commits touching several
> > files and keeping track of what's been changed between versions via an
> > email conversation isn't attractive to me, nor is trying to keep track of
> > which change-sets have been applied, rejected, or are waiting for
> > revisions.
> >
> > Yeah, the linux kernel uses 

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Frank H. Ellenberger]

…and the bug report is?

Am 06.12.21 um 07:41 schrieb Kevin Buckley:
> It seems I can't, so I now have an account there and have added
> the patch to the "bug report"
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Geert Janssens]

Well, it wasn't just Kevin's patch submission by mail that triggered my 
reaction.

I recently also read this blog post
https://blog.brixit.nl/git-email-flow-versus-github-flow/[1]

Though as it didn't really apply to gnucash directly I only read it 
superficially back then. 
Rereading it more closely I gather the git mail process can be made more 
attractive by 
adding a web-based tool that displays mailing list messages in a way optimized 
for typical git 
mail conversations.
I'll also note the author apparently is allergic to merge commits which we are 
not so his 
heavy focus on that argument is a little weak.

I'm not really interested in promoting such an approach. It did trigger an 
academic curiosity 
towards it though as it seems to have it's own distinct advantages and 
drawbacks.

I'll elaborate on what I perceive just for the sake of provoking thoughts.

For example, the author refers to github's merge facility (which is in his 
opinion subpar as it 
generates merge commits). We can't actually use that as we have declared our 
repos on 
code to be the master repos. Yet as I'm usually working on the command line to 
steer git, 
using git am to apply mail patches would save me a number of context switches.
>From a user point of view that same command line efficiency is possible with 
>git mail. In 
addition not everyone wants to have an account on github for various reasons, 
but I 
presume those same people are willing to send mails directly to the project.

Specifically to your first objection (large complex patches needing much 
discussion). I didn't 
suggest to make it the only or even the primary channel to submit patches. We 
could still 
request a formal PR on github if the patch becomes too complex or rely on the 
suggested 
web-based tool to make that process easier for us.

Clearly there are also downsides. Firstly there is the maintenance of yet 
another website. 
Additionally much of the benefit of direct mail workflow is gone if you still 
have to visit a 
website to be able to follow the review conversation...

And with that I'll step down from my soapbox :)
I do not plan to pursue this further myself as I don't think there's enough net 
benefit for 
gnucash.

Regards,

Geert

Op zondag 5 december 2021 23:17:41 CET schreef John Ralls:
> Geert,
> 
> Reviewing and commenting a big patch with several commits touching several
> files and keeping track of what's been changed between versions via an
> email conversation isn't attractive to me, nor is trying to keep track of
> which change-sets have been applied, rejected, or are waiting for
> revisions.
> 
> Yeah, the linux kernel uses mailing lists and a huge posse of designated
> maintainers for handling patches. There doesn't seem to be any documented
> system for keeping track of the patches, just an exhortation to submitters
> to rebase and resubmit frequently during the limited "merge windows" at the
> beginning of each development cycle. It sure seems to me--and likely to
> most everyone else in the FLOSS community--that learning to use GitHub or
> GitLab as a prerequisite for patch submission is the less painful route.
> 
> Regards,
> John Ralls
> 
> > On Dec 5, 2021, at 1:07 PM, Geert Janssens 
> > wrote:
> > 
> > I actually wonder whether we should reconsider our strategy.
> > 
> > We're pretty used to the convenience of github pull requests. But patches
> > by mail are actually the main method offered by git itself. So forcing
> > potential contributors to go manipulate a website in order to get a patch
> > sent is is counterproductive to people accustomed to the git mail
> > process.
> > 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Frank H. Ellenberger]

+1

Am 05.12.21 um 23:17 schrieb John Ralls:
> Geert,
> 
> Reviewing and commenting a big patch with several commits touching several 
> files and keeping track of what's been changed between versions via an email 
> conversation isn't attractive to me, nor is trying to keep track of which 
> change-sets have been applied, rejected, or are waiting for revisions.
> 
> Yeah, the linux kernel uses mailing lists and a huge posse of designated 
> maintainers for handling patches. There doesn't seem to be any documented 
> system for keeping track of the patches, just an exhortation to submitters to 
> rebase and resubmit frequently during the limited "merge windows" at the 
> beginning of each development cycle. It sure seems to me--and likely to most 
> everyone else in the FLOSS community--that learning to use GitHub or GitLab 
> as a prerequisite for patch submission is the less painful route.
> 
> Regards,
> John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Kevin Buckley]

On Mon, 6 Dec 2021 at 13:48, Kevin Buckley  wrote:
>
> Only went with the patch by email to save me having to login to GitHub,
> as I only maintain a local copy of the maint branch, not one forked to an
> identity at GitHub.
>
> Can I submit via the bugzilla without needing a login on anything?

It seems I can't, so I now have an account there and have added
the patch to the "bug report"
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Kevin Buckley]

On Sun, 5 Dec 2021 at 22:34, Derek Atkins  wrote:
>
> Hi,
>
> On Sun, December 5, 2021 8:55 am, D. via gnucash-devel wrote:
> > Kevin,
> >
> > The preferred way to submit changes is through git PRs, not with patch
> > files attached to emails to the lists. You'll get better results using
> > that method.
>
> I would add that there are two preferred methods:
>
> 1) Github PR
> 2) Patch attached to a bugzilla report.
>
> Patches sent in email are likely to get lost or forgotten.  Sending them
> via bugzilla and github are less prone to loss.
>
> Also, for the record, the patch did NOT make it through the mailing list's
> "purge HTML" process and into my inbox -- so it is already lost!

Bugger!

Only went with the patch by email to save me having to login to GitHub,
as I only maintain a local copy of the maint branch, not one forked to an
identity at GitHub.

Can I submit via the bugzilla without needing a login on anything?

As for any "sorrow for your loss", well I have since found another
couple of similar typos anyway, so I'll get another go!

Kevin
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[John Ralls]

Geert,

Reviewing and commenting a big patch with several commits touching several 
files and keeping track of what's been changed between versions via an email 
conversation isn't attractive to me, nor is trying to keep track of which 
change-sets have been applied, rejected, or are waiting for revisions.

Yeah, the linux kernel uses mailing lists and a huge posse of designated 
maintainers for handling patches. There doesn't seem to be any documented 
system for keeping track of the patches, just an exhortation to submitters to 
rebase and resubmit frequently during the limited "merge windows" at the 
beginning of each development cycle. It sure seems to me--and likely to most 
everyone else in the FLOSS community--that learning to use GitHub or GitLab as 
a prerequisite for patch submission is the less painful route.

Regards,
John Ralls



> On Dec 5, 2021, at 1:07 PM, Geert Janssens  wrote:
> 
> I actually wonder whether we should reconsider our strategy.
> 
> We're pretty used to the convenience of github pull requests. But patches by 
> mail are 
> actually the main method offered by git itself. So forcing potential 
> contributors to go 
> manipulate a website in order to get a patch sent is is counterproductive to 
> people 
> accustomed to the git mail process.
> 
> I agree this mailing list may not be the proper destination for such mails 
> but nothing stops 
> us from also setting up a mailing list specifically to accept patches. It 
> can't be gnucash-
> patches as we already use that for other purposes. But we can come up with 
> another one.
> 
> Note that also for us maintainers applying patches received by mail is not 
> cumbersome at 
> all. Git has commands built in for that. The cumbersome part may come from 
> getting the 
> mail out of your mail client into a directory structure where it can be read 
> by git. If your mail 
> client is maildir based, that very mail directory is already in the right 
> format to start with. 
> Otherwise it may require some save action on behalf of the maintainer. That's 
> not more 
> difficult than what we currently do with bugzilla patches (which I'd rather 
> drop in favour of 
> mail based patches as the latter has git integration and the former hasn't).
> 
> I'm interested what others think of this.
> 
> Regards,
> 
> Geert
> 
> Op zondag 5 december 2021 15:34:45 CET schreef Derek Atkins:
>> Hi,
>> 
>> On Sun, December 5, 2021 8:55 am, D. via gnucash-devel wrote:
>>> Kevin,
>>> 
>>> The preferred way to submit changes is through git PRs, not with patch
>>> files attached to emails to the lists. You'll get better results using
>>> that method.
>> 
>> I would add that there are two preferred methods:
>> 
>> 1) Github PR
>> 2) Patch attached to a bugzilla report.
>> 
>> Patches sent in email are likely to get lost or forgotten.  Sending them
>> via bugzilla and github are less prone to loss.
>> 
>> Also, for the record, the patch did NOT make it through the mailing list's
>> "purge HTML" process and into my inbox -- so it is already lost!
>> 
>>> David T.
>> 
>> -derek
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Geert Janssens]

I actually wonder whether we should reconsider our strategy.

We're pretty used to the convenience of github pull requests. But patches by 
mail are 
actually the main method offered by git itself. So forcing potential 
contributors to go 
manipulate a website in order to get a patch sent is is counterproductive to 
people 
accustomed to the git mail process.

I agree this mailing list may not be the proper destination for such mails but 
nothing stops 
us from also setting up a mailing list specifically to accept patches. It can't 
be gnucash-
patches as we already use that for other purposes. But we can come up with 
another one.

Note that also for us maintainers applying patches received by mail is not 
cumbersome at 
all. Git has commands built in for that. The cumbersome part may come from 
getting the 
mail out of your mail client into a directory structure where it can be read by 
git. If your mail 
client is maildir based, that very mail directory is already in the right 
format to start with. 
Otherwise it may require some save action on behalf of the maintainer. That's 
not more 
difficult than what we currently do with bugzilla patches (which I'd rather 
drop in favour of 
mail based patches as the latter has git integration and the former hasn't).

I'm interested what others think of this.

Regards,

Geert

Op zondag 5 december 2021 15:34:45 CET schreef Derek Atkins:
> Hi,
> 
> On Sun, December 5, 2021 8:55 am, D. via gnucash-devel wrote:
> > Kevin,
> > 
> > The preferred way to submit changes is through git PRs, not with patch
> > files attached to emails to the lists. You'll get better results using
> > that method.
> 
> I would add that there are two preferred methods:
> 
> 1) Github PR
> 2) Patch attached to a bugzilla report.
> 
> Patches sent in email are likely to get lost or forgotten.  Sending them
> via bugzilla and github are less prone to loss.
> 
> Also, for the record, the patch did NOT make it through the mailing list's
> "purge HTML" process and into my inbox -- so it is already lost!
> 
> > David T.
> 
> -derek


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Derek Atkins]

Hi,

On Sun, December 5, 2021 8:55 am, D. via gnucash-devel wrote:
> Kevin,
>
> The preferred way to submit changes is through git PRs, not with patch
> files attached to emails to the lists. You'll get better results using
> that method.

I would add that there are two preferred methods:

1) Github PR
2) Patch attached to a bugzilla report.

Patches sent in email are likely to get lost or forgotten.  Sending them
via bugzilla and github are less prone to loss.

Also, for the record, the patch did NOT make it through the mailing list's
"purge HTML" process and into my inbox -- so it is already lost!

> David T.

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[D. via gnucash-devel]

Kevin, 

The preferred way to submit changes is through git PRs, not with patch files 
attached to emails to the lists. You'll get better results using that method. 

David T.


 Original Message 
From: Kevin Buckley 
Sent: Sun Dec 05 01:35:12 EST 2021
To: "Frank H. Ellenberger" 
Cc: gnucash-devel 
Subject: Re: [GNC-dev] Small changes to comment text, mostly in 
gnucash/import-export/import-main-matcher.h

On Wed, 1 Dec 2021 at 22:40, Frank H. Ellenberger
 wrote:
>
> Hi Kevin,
>
> don't forget to CC the list.
>
> Am 01.12.21 um 03:22 schrieb Kevin Buckley:
> > On Sat, 27 Nov 2021 at 23:36, Frank H. Ellenberger
> >  wrote:
> >>
> >> Hi Kevin,
> >>
> >> The comments containing "@param" are doxygen sources. How looks the reesult
> >> https://code.gnucash.org/docs/MAINT/import-main-matcher_8h.html and links?
> >>
> >> Regards
> >> Frank
> >
> > Yes the "a the" is visible there too.
> >
> > If I navigate through to, say,
> >
> > https://code.gnucash.org/docs/MAINT/group__Import__Export.html#gad26d36e9e962bb4ba174d697f59f25fb
> >
> > which is the doc for this fucntion
> >
> > gnc_gen_trans_list_empty()
> >
> > I see
> >
> > gboolean gnc_gen_trans_list_empty ( GNCImportMainMatcher *  info)
> >
> > Checks whether there are no transactions to match.
> >
> > Parameters
> > info A pointer to a the GNCImportMainMatcher structure.
> >
> > so the "a the" is in there too.
> >
> > FWIW, I have noticed a few other typos and spelling corrections in
> > the comments, so maybe I should clone the repo and submit a PR
> > with them all in?
>
> Yes, that would be the best approach.
> See also https://wiki.gnucash.org/wiki/Doxygen
>
> Regards
> Frank

Find a patch from a `git diff -p -stat` attached.




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Kevin Buckley]

On Wed, 1 Dec 2021 at 22:40, Frank H. Ellenberger
 wrote:
>
> Hi Kevin,
>
> don't forget to CC the list.
>
> Am 01.12.21 um 03:22 schrieb Kevin Buckley:
> > On Sat, 27 Nov 2021 at 23:36, Frank H. Ellenberger
> >  wrote:
> >>
> >> Hi Kevin,
> >>
> >> The comments containing "@param" are doxygen sources. How looks the reesult
> >> https://code.gnucash.org/docs/MAINT/import-main-matcher_8h.html and links?
> >>
> >> Regards
> >> Frank
> >
> > Yes the "a the" is visible there too.
> >
> > If I navigate through to, say,
> >
> > https://code.gnucash.org/docs/MAINT/group__Import__Export.html#gad26d36e9e962bb4ba174d697f59f25fb
> >
> > which is the doc for this fucntion
> >
> > gnc_gen_trans_list_empty()
> >
> > I see
> >
> > gboolean gnc_gen_trans_list_empty ( GNCImportMainMatcher *  info)
> >
> > Checks whether there are no transactions to match.
> >
> > Parameters
> > info A pointer to a the GNCImportMainMatcher structure.
> >
> > so the "a the" is in there too.
> >
> > FWIW, I have noticed a few other typos and spelling corrections in
> > the comments, so maybe I should clone the repo and submit a PR
> > with them all in?
>
> Yes, that would be the best approach.
> See also https://wiki.gnucash.org/wiki/Doxygen
>
> Regards
> Frank

Find a patch from a `git diff -p -stat` attached.
 gnucash/gnome-utils/gnc-main-window.h|  6 +++---
 gnucash/gnome-utils/gnc-tree-view-commodity.h|  2 +-
 gnucash/import-export/import-main-matcher.h  | 16 
 gnucash/register/register-gnome/gnucash-sheet.c  |  2 +-
 libgnucash/app-utils/calculation/expression_parser.c |  2 +-
 libgnucash/app-utils/gnc-sx-instance-model.c |  2 +-
 libgnucash/engine/qofid.h|  2 +-
 7 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/gnucash/gnome-utils/gnc-main-window.h b/gnucash/gnome-utils/gnc-main-window.h
index 35b70d588..305494e73 100644
--- a/gnucash/gnome-utils/gnc-main-window.h
+++ b/gnucash/gnome-utils/gnc-main-window.h
@@ -361,7 +361,7 @@ void gnc_main_window_restore_all_windows(const GKeyFile *keyfile);
  *  used on report pages to delay the creation of the report till the
  *  page is focused.
  *
- *  @param window When window whose pages should be checked.
+ *  @param window The window whose pages should be checked.
  *
  *  @return TRUE if pages are being restored
  */
@@ -383,7 +383,7 @@ void gnc_main_window_restore_default_state(GncMainWindow *window);
  *  If any page returns a failure indication, then the function stops
  *  walking pages and immediately returns a failure.
  *
- *  @param window When window whose pages should be checked.
+ *  @param window The window whose pages should be checked.
  *
  *  @return FALSE if any page could not or would not comply, which
  *  should cancel the pending operation.  TRUE otherwise */
@@ -412,7 +412,7 @@ void gnc_main_window_all_action_set_sensitive (const gchar *action_name, gboolea
 
 /** Find action in main window.
  *
- *  @param window When window which should be checked for the action.
+ *  @param window The window which should be checked for the action.
  *
  *  @param name The name of the command to be retrieved.
  *
diff --git a/gnucash/gnome-utils/gnc-tree-view-commodity.h b/gnucash/gnome-utils/gnc-tree-view-commodity.h
index eeacdeb7b..1f7e80bb5 100644
--- a/gnucash/gnome-utils/gnc-tree-view-commodity.h
+++ b/gnucash/gnome-utils/gnc-tree-view-commodity.h
@@ -208,7 +208,7 @@ gnc_commodity * gnc_tree_view_commodity_get_selected_commodity  (GncTreeViewComm
  *
  *  @param view A pointer to an commodity tree view.
  *
- *  @param The commodity to select.
+ *  @param commodity The commodity to select.
  */
 void gnc_tree_view_commodity_select_commodity (GncTreeViewCommodity *view, gnc_commodity *commodity);
 
diff --git a/gnucash/import-export/import-main-matcher.h b/gnucash/import-export/import-main-matcher.h
index 490d54c44..51ddf4f53 100644
--- a/gnucash/import-export/import-main-matcher.h
+++ b/gnucash/import-export/import-main-matcher.h
@@ -112,7 +112,7 @@ GNCImportMainMatcher * gnc_gen_trans_assist_new (GtkWidget *parent,
 /**  This starts the import process for transaction from an assistant.
  *   assistant button callback.
  *
- * @param info. A pointer to a the GNCImportMainMatcher structure.
+ * @param info. A pointer to the GNCImportMainMatcher structure
 */
 void gnc_gen_trans_assist_start (GNCImportMainMatcher *info);
 
@@ -177,38 +177,38 @@ void gnc_gen_trans_list_add_trans_with_ref_id (GNCImportMainMatcher *gui,
 /** Run this dialog and return only after the user pressed Ok, Cancel,
   or closed the window. This means that all actual importing will
   have been finished upon returning.
- * @param info A pointer to a the GNCImportMainMatcher structure.
+ * @param info A pointer to the GNCImportMainMatcher structure.
  * @return The boolean return value of the dialog run.
 */
 gboolean gnc_gen_trans_list_run (GNCImportMainMatcher *info);
 
 
 /** Returns the widget of this 

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Frank H. Ellenberger]

Hi Kevin,

don't forget to CC the list.

Am 01.12.21 um 03:22 schrieb Kevin Buckley:
> On Sat, 27 Nov 2021 at 23:36, Frank H. Ellenberger
>  wrote:
>>
>> Hi Kevin,
>>
>> The comments containing "@param" are doxygen sources. How looks the reesult
>> https://code.gnucash.org/docs/MAINT/import-main-matcher_8h.html and links?
>>
>> Regards
>> Frank
> 
> Yes the "a the" is visible there too.
> 
> If I navigate through to, say,
> 
> https://code.gnucash.org/docs/MAINT/group__Import__Export.html#gad26d36e9e962bb4ba174d697f59f25fb
> 
> which is the doc for this fucntion
> 
> gnc_gen_trans_list_empty()
> 
> I see
> 
> gboolean gnc_gen_trans_list_empty ( GNCImportMainMatcher *  info)
> 
> Checks whether there are no transactions to match.
> 
> Parameters
> info A pointer to a the GNCImportMainMatcher structure.
> 
> so the "a the" is in there too.
> 
> FWIW, I have noticed a few other typos and spelling corrections in
> the comments, so maybe I should clone the repo and submit a PR
> with them all in?

Yes, that would be the best approach.
See also https://wiki.gnucash.org/wiki/Doxygen

Regards
Frank
Frank
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Frank H. Ellenberger]

Hi Kevin,

The comments containing "@param" are doxygen sources. How looks the reesult
https://code.gnucash.org/docs/MAINT/import-main-matcher_8h.html and links?

Regards
Frank

Am 25.11.21 um 06:58 schrieb Kevin Buckley:
> For reasons I'll not go into (?!) I happened to notice that  there
> are a few  places in the source where the text reads, eg,
> 
> * @param info. A pointer to a the   structure
> 
> Not clear if the "a the" was meant, but, as there are a shedload of
> "A pointer to the " strings, but no "A pointer to a "
> strings that I could grep, in case it helps tidy up the codebase, a recent 
> grep
> on the maint branch returned:
> 
> ./gnucash/import-export/import-main-matcher.h: * @param info. A
> pointer to a the GNCImportMainMatcher structure.
> ./gnucash/import-export/import-main-matcher.h: * @param info A pointer
> to a the GNCImportMainMatcher structure.
> ./gnucash/import-export/import-main-matcher.h: * @param info A pointer
> to a the GNCImportMainMatcher structure.
> ./gnucash/import-export/import-main-matcher.h: * @param info A pointer
> to a the GNCImportMainMatcher structure.
> ./gnucash/import-export/import-main-matcher.h: * @param info A pointer
> to a the GNCImportMainMatcher structure.
> ./gnucash/import-export/import-main-matcher.h: * @param info A pointer
> to a the GNCImportMainMatcher structure.
> ./gnucash/import-export/import-main-matcher.h: * @param info A pointer
> to a the GNCImportMainMatcher structure.
> ./libgnucash/engine/gnc-numeric.h: *  @param a the ::gnc_numeric value
> to convert
> ./libgnucash/app-utils/calculation/expression_parser.c: * The
> first parameter is a pointer to a the first element in
> 
> I also note that the first of those has a periof after the parameter name,
> whilst none of the others do.
> 
> HTH, and thanks, as always, for GnuCash,
> Kevin
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Kevin Buckley]

For reasons I'll not go into (?!) I happened to notice that  there
are a few  places in the source where the text reads, eg,

* @param info. A pointer to a the   structure

Not clear if the "a the" was meant, but, as there are a shedload of
"A pointer to the " strings, but no "A pointer to a "
strings that I could grep, in case it helps tidy up the codebase, a recent grep
on the maint branch returned:

./gnucash/import-export/import-main-matcher.h: * @param info. A
pointer to a the GNCImportMainMatcher structure.
./gnucash/import-export/import-main-matcher.h: * @param info A pointer
to a the GNCImportMainMatcher structure.
./gnucash/import-export/import-main-matcher.h: * @param info A pointer
to a the GNCImportMainMatcher structure.
./gnucash/import-export/import-main-matcher.h: * @param info A pointer
to a the GNCImportMainMatcher structure.
./gnucash/import-export/import-main-matcher.h: * @param info A pointer
to a the GNCImportMainMatcher structure.
./gnucash/import-export/import-main-matcher.h: * @param info A pointer
to a the GNCImportMainMatcher structure.
./gnucash/import-export/import-main-matcher.h: * @param info A pointer
to a the GNCImportMainMatcher structure.
./libgnucash/engine/gnc-numeric.h: *  @param a the ::gnc_numeric value
to convert
./libgnucash/app-utils/calculation/expression_parser.c: * The
first parameter is a pointer to a the first element in

I also note that the first of those has a periof after the parameter name,
whilst none of the others do.

HTH, and thanks, as always, for GnuCash,
Kevin
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel