emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more than one prefix argument


From: Tim Cross
Subject: Re: more than one prefix argument
Date: Wed, 27 Jul 2011 19:38:19 +1000

On Wed, Jul 27, 2011 at 7:25 PM, Tim Cross <address@hidden> wrote:
> On Wed, Jul 27, 2011 at 4:25 PM, Andreas Röhler
> <address@hidden> wrote:
>> Am 26.07.2011 22:36, schrieb Drew Adams:
>>>>>
>>>>> what about allowing more than one prefix argument
>>>>> by making interactive codes "p" and "P" sending
>>>>> truly separated.
>>>>
>>>> We already have more than one kind of prefix argument: see
>>>> universal-coding-system-argument for an example.  You can
>>>> already define as many kinds of "prefix argument" as you'd
>>>> like: just define a global flag and a command to set that
>>>> flag, and have post-command-hook clear the flag unless (eq
>>>> this-command 'my-prefix-setting-function).
>>>
>>> I don't think that's what Andreas is asking about.  He's not asking about
>>> being
>>> able to define alternative "prefix arg"-like things (to be used
>>> separately).  I
>>> think he wants the same user input to somehow distinguish two different
>>> things
>>> (?).
>>>
>>> At least that's my understanding.  IMO, he is simply confused,
>>
>> Hi Drew,
>>
>> maybe you are right. Then we must wait. I'll try to sum up the matter for
>> the moment:
>>
>> current use of "p" and "P" might be enhanced. There is an intermix between
>> both, doing nearly, but not precisely, the same.
>>
>> "P" quite often is used for completely different things than sending a
>> number.
>>
>> (if (eq 4 (prefix-numeric-value))
>>
>> is used as a branch command. That's the interesting about it indeed.
>>
>> However, that's not clean. It's bad to read, because the fact of "4" has no
>> meaning by themselves here. That's obscure programming style.
>>
>> In general let me stress: I'm living very well with Emacs as it is. Just
>> saying: we can live still better.
>>
>> Cheers and thanks,
>>
>> Andreas
>>
>
> While P and p are similar, I'm not sure they are as similar as you
> imply. Consider a very simple example. You have a function and you
> want it to use a prefix arg and you want the raw form because you want
> to distinguish between no prefix arg and C-u 1 or M-1. You then define
> a second function, but this time, you want it to default to 1 if no
> prefix arg or whatever the value is if one is provided, then the 'p'
> numeric version is what you want. In each case, the P and p support
> what you need without you having to do additional code. Yes, you could
> solve this with just the P version, but then you would have to do more
> code to handle the common case of just wanting to process the prefix
> arg as a number.
>
> This additional code would likely make the reading of the source even
> more difficult than your example issue with the use of '4' in your
> example. I would also suggest that if you don't like the literal 4 as
> it doesn't make it clear what is going on (why 4?) you could define a
> variable, such as
>

Oops - hit send before I was ready!

what I was going to say is that using a literal 4 can be seen as
possibly poor style because it does not convey much meaning regarding
code intention. However, I would expect if that was a concern, instead
of a literal 4, you would use a variable which is bound to that value
and which has a name that more accurately expresses meaning/intention.
So, while this may be a valid point, I don't see it as specific to the
us of P or p.

What I don't understand is what you are proposing as an alternative
and why it would be better. Just getting rid of 'p' and keeping 'P'
doesn't seem to buy us anything except we now have to explicitly
convert to numeric values when we want them. We can't not have 'P' as
sometimes we need to distinguish between 1 and nil. Having both seems
a useful convenience.

I don't know if Drew's assessment of what you are asking is correct or
not, but I do think you need to clarify your argument and suspect his
suggestion concerning more thought may be correct.

Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]