[MPlayer-dev-eng] [PATCH] printf --> mp_msg transition (mplayer.c)

[The Wanderer]

Diego Biurrun wrote:

> The Wanderer writes:
> 
>> Diego Biurrun wrote:
>> 
>>> Editing patches in emacs should also work, it has a nice patch
>>> mode, I've often done this to split up patches.
>> 
>> I have yet to get to the point where I can actually use emacs; even
>> the comparatively minimal interface familiarity needed for getting
>> into and navigating its tutorial/help/internal-documentation mode
>> is more complication than I've been able to handle. I'd like to use
>> it, but that hump is one I have just not yet managed to get over.
> 
> Type M-x help-with-tutorial, you should have mastered the basics half
> an hour after that.

<makes note>

Next time I have a half-hour to spare and don't feel restless, I'll have
to remember to do that.

>>> I'm in the dark here.  Maybe you have some sticky or something
>>> tags on parts of your WD, these are known to cause obscure
>>> problems now and then.  Try "cvs update -dPA" to reset them.
>> 
>> I always use that anyway - I have a nice little "update_cvs" file
>> in the root of every CVS source tree on my machine, with whatever
>> flags I need to get the latest version from that repository, to
>> save myself from having to remember what to use where (or for that
>> matter from typing it all out every time); '-dPA' is there in all
>> of them. So it looks like we're both quite confused.
> 
> You could also add the options to your ~/.cvsrc, here's mine:
> 
> cvs -q -z3
> diff -u
> update -dPA

...you know, that'd help quite a bit.

I'd still want to have the per-tree one-line scripts, because in some
cases I need to specify a particular branch in order to get the code I
want (and with the scripts all having the same name, I don't have to
remember what command to use where), but this could cut down on
duplication somewhat.

>> I'm currently going through codecs-cfg.c and removing printfs; I'm
>> not entirely certain that it really should be changed (because the
>> things printed seem designed to be written directly into a file,
>> implying that they don't get printed on the console anyway), but it
>> wasn't mentioned when I asked about which files shouldn't be
>> transitioned, so because it does already include mp_msg.h I'm going
>> ahead with it anyway. I am, however, uncertain as to what messages
>> should and should not be moved for translation - it would help
>> (though not much) if I at least knew what the code in that file
>> actually is used for. Many of them seem to be 
>> translation-appropriate, but... something seems different here.
> 
> codec-cfg is used to create the codecs-status.html document from the
> template DOCS/tech/codecs-in.html and etc/codecs.conf.  I think it 
> does some more things as well that I cannot remember off the top of
> my head.  Somehow I doubt this is worth translating or spending much
> time on, so I suggest you tackle other areas first before this one.

Too late, already done and sent; the thing I was asking about turned out
to be less important than I'd thought it was, once I figured a few
things out. I was going through in alphabetical order after finishing
the two top-level files (to make sure I didn't skip anything), and this
was the first thing up. It wasn't a complete waste in any case, even if
the changes get rejected, because I've learned something in the process.

I will, however, move on to something else now; that was too quick and
too easy to stop there.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.