Introduce run_listbox_with_data()

[mooffie]

The problem:

Functions that use run_listbox() can be complicated and breakable, if they need to figure out some pointer given the number of the item selected.

(For example, in the case of ​edit_window_list() this will make its code break if we change how widgets are Z-ordered --which was the 1st solution I tried for #3760.)

The solution:

A listbox can already store pointers. So we introduce a variant of run_listbox() which returns pointers. We then use it to simplify a couple of functions.

[mooffie]

branch: 3763_run_listbox_with_data
Initial changeset:11c1aff4d343096ef555b7fcec05a625f2e020c2

(There are 3 commits here.)

[zaytsev]

LGTM, Andrew?

Minor comment: the pointer WEdit *e can be WEdit * const e unless I'm confused, but that might be my Haskell habits :-|

[mooffie]

If this ticket gets approved, before I commit I'll change:

if (e != NULL)
    val = e->data;

to:

if (e != NULL) {
    g_assert (!e->free_data); /* Don't return pointers that are about to be deallocated, as in listbox_add_item(..., TRUE). */
    val = e->data;
}

[mooffie]

Replying to zaytsev:

Minor comment: the pointer WEdit *e can be WEdit * const e unless I'm confused

Could you please elaborate? (I'm sure I'm about to learn new stuff.)

(Haskell... I programmed in it for over a year. It was the language I found the most joyous to use.)

[zaytsev-work]

If this ticket gets approved, before I commit...

Suggest to commit with --fixup and then, before you merge with --no-ff, just do a rebase -i --autosquash and it will reorder & squash the commits automatically. You probably know about that already, but thought I'd mention it anyways.

[mooffie]

So, folks, is this "approved"?

(Can I assume when somebody writes "LGTM" that he's voting for it?)

Replying to zaytsev-work:

Suggest to commit with --fixup

Yes, Andrew once explained this to me (I already suqashed the branch: I had the impression it was "approved").

[zaytsev]

LTGM = looks good to me, sorry about that. Yes, sometimes we forget to change the status after adding votes, fixed this just now. I'm afraid that's all I can do for now, need to go to sleep.

[mooffie]

Merged to master: [b39c1b94465a76b6b84ac8955fa0ff6385dd0ca3]

[mooffie]

(Yes, I updated NEWS-4.8.19.)

Sweet dreams!

[zaytsev]

Could you please elaborate? (I'm sure I'm about to learn new stuff.)

I'm afraid that you'd be left disappointed by my insights :-/ (now that I've finally gotten to it)

All I meant is that in this situation it appeared to me that you don't need the capability to reseat the pointer, and so in such cases I would always use a "type * const" pointer to prevent reseating it by accident. Unfortunately, there are no references in C like in C++ (special syntax for pointers that can't be reseated after initialization), and so it's a bit clumsy to use, but it feels a bit safer.

This where the Haskell reference comes in; as you know, there immutability is ubiquitous and manipulating mutable objects requires explicit opt-in as in choosing a special type, using ST monad and what not. Consequently, after having programmed in Haskell, I feel physically unwell when I have to manipulate mutable objects, and therefore if I have to do C/C++, I tend to use "type const * const" when possible, or, at least, "type * const", when one has to be able to modify the value, but doesn't need to be able to reseat the pointer. Another facet of this paranoia is to use stack when possible and break down code in blocks to declare variables local to the block, limiting the scope to furthest possible extent (in mc sources you will find monster functions that can be so broken down in many blocks, which actually hints at that their McCabe number is way too high, and they have to be refactored anyways, but that's another story...).

There really isn't much more to it, and now, I can't even seem to find the WEdit *e that I was referencing here, which is probably what confused you, so apparently, I was looking at several tickets at the same time, and posted this comment in the wrong ticket. Sorry about that...