I wondered how you did that. Now I know.

Well, I was doing the lion's share of my markup by hand. But I realized that small-caps was a markup I used often enough that being able to invoke it with a single key chord would save me significant typing, so I went and figured out how to add it in.

In addition to this patch, I build LogJam with a patch to the menus that adds a few extra hotkeys (Ctl+F to open a file, Ctl+D to open a draft) and rearranges the menus into an order that's more intuitive for me (LogJam, Edit, View, Journal, Entry, Insert, HTML). This menu order also turns out to group the menus I most frequently use close together, and as a free bonus, makes it easier to rearrange the order of the top-level menus.

Disclaimer: I am not the maintainer.

Why don't you make a version of html_mark_tag that doesn't take a params argument and instead just passes (char*)NULL to the 3 argument version.

Your patch would be smaller, and smaller patches are accepted quicker, in my experience.

(1) It would add the overhead of an additional function call to all of the simple markups that do not require parameters, as well as requiring two different function calls for markup functions solely to put off passing a NULL.

(2) Adding a wrapper function that's close to a NOP would obfuscate what is basically very simple code, for no real reason or functional gain.

And (3) it would be a bigger functional change to the code, for the sake of an only marginally smaller patch.

Oh, and four, I have a personal distaste for near-NOP wrapper functions ....


"I'm sorry -- we'll come in again."
</ObPython>

I'd buy (2) and (3) but your less-overhead argument looks silly for a GUI app that should be written in Perl or Python anyway.

(the only reason LogJam isn't in a HLL already is because distros historically haven't shipped GTK/GNOME bindings... but that might change with GNOME 2.8/)

That "should be written in Perl or Python" is a religious argument that I'm just not going to get into, beyond stating that I disagree with it. That said, I'd love a decent (and DECENTLY DOCUMENTED!) Perl interface to GTK+, because Tk (IMHO) is ass.

Me saying Perl or Python was meant to avoid the religious debate. I don't give a damn what HLL language people use... they're all largely the same. But I don't think you should use a systems langauge (C) for a freakin' GUI app with a text box and a submit button. That's inviting bugs, security issues, wasting programmer time, etc, etc.

And yeah, Tk is ass, and GTK.pm has/had/has its problems, which is probably why people keep writing GTK/GNOME apps in C.

Have I missed the boat or is not

html_mark_tag(doc, "span style=\"font-variant: small-caps\"");

a simpler and better way of doing this. Any argument you make about the advantages of passing in params seperate from the tag are completly moot, largly because of the half assed nature of your "new" html_mark_tag function. Seriously if you want to pass the tag and parameters seperate make it a variable arguments function, not only is it general purpose that way, you get the added bonus of not having to change 5 other functions. Unless of course you like turning 10 line patches into 22 line ones.

the parameter is used verbatim for both the opening and closing tags. in a closing tag, the attributes are unnecessary (and probably invalid?).

re the patch: i agree with brad's comment above, but i also don't mind this way. though why the cast on NULL?

It apears that I had missed the boat. I'd almost rather string process the argument, or more likly use the variable arguments.

I cast the NULL because without the cast, gcc was emitting warnings (integer converted to pointer without a cast) on those lines. Granted, it's only a warning, and it does no harm, but when the warning could be eliminated with a simple cast....

Variable args would be another (and probably better) way to do it, indeed. I simply didn't think of it at the time. I'll look into doing it that way.

OK, rewritten to use stdarg, same URL, updated patch. You're right, it is mo' bettah this way. Don't ask me why I didn't think of it myself, because I hate having to say "Uuhhhhhhhhhh..." and sit there with my jaw slack while I try to think of a good answer.