From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.bugs Subject: bug#21648: 25.0.50; [PATCH] Add ability to specify radix for the yanked number in calc-yank Date: Thu, 8 Oct 2015 12:59:11 -0400 Message-ID: References: <87oag9fim6.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0153716c8cc04405219aca8b X-Trace: ger.gmane.org 1444324756 7944 80.91.229.3 (8 Oct 2015 17:19:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Oct 2015 17:19:16 +0000 (UTC) To: Jay Belanger , 21648@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 08 19:19:05 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from eggs.gnu.org ([208.118.235.92]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZkEqO-0002tp-8U for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Oct 2015 19:19:04 +0200 Original-Received: from lists.gnu.org ([208.118.235.17]:43858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkEqN-0007SH-Tf for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Oct 2015 13:19:03 -0400 Original-Received: from localhost ([::1]:36189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkEqN-00040p-P5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Oct 2015 13:19:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkEZB-0003Fz-RV for bug-gnu-emacs@gnu.org; Thu, 08 Oct 2015 13:02:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkEY2-0006l5-Aq for bug-gnu-emacs@gnu.org; Thu, 08 Oct 2015 13:01:17 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkEY2-0006kS-0e for bug-gnu-emacs@gnu.org; Thu, 08 Oct 2015 13:00:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZkEY1-0004T3-8c for bug-gnu-emacs@gnu.org; Thu, 08 Oct 2015 13:00:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kaushal Modi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Oct 2015 17:00:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 21648-submit@debbugs.gnu.org id=B21648.144432359417120 (code B ref 21648); Thu, 08 Oct 2015 17:00:05 +0000 Original-Received: (at 21648) by debbugs.gnu.org; 8 Oct 2015 16:59:54 +0000 Original-Received: from localhost ([127.0.0.1]:32866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZkEXp-0004S2-FB for submit@debbugs.gnu.org; Thu, 08 Oct 2015 12:59:54 -0400 Original-Received: from mail-ob0-f172.google.com ([209.85.214.172]:34730) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZkEXn-0004Rt-9r for 21648@debbugs.gnu.org; Thu, 08 Oct 2015 12:59:52 -0400 Original-Received: by obbda8 with SMTP id da8so43269626obb.1 for <21648@debbugs.gnu.org>; Thu, 08 Oct 2015 09:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KfoavZCsGVGV6zUUuapIHKHupki3RvlxnP448TgvDJQ=; b=PNCZdCFq+4pulX7auvVzcDRB6uf2p4S3gzwzh3Nvr8uFSzpAVFz5gD4QrVZyMudqc6 ySrGfIaqKNCaINMGFnEWU00/DqAsMZ9le27aNL1LQz8AxdIsQ5/5UXVZ/CdUkPFuIEso CALKhpDxaZLJiDHX/TouE7Zz86MsaLqegCCaN7vcc7D3bgHohIJVoe9Fp1++b5bOhPM9 7FRAsbeKS08OxLSzuAFnJN6UgoAcV8JiZ1RHzG2tonIzRhIHe+b2LBGP02wpOXPeq8+9 BWroUZ6ZBcCYoPu35t6hG3JALoFWxNgw7HEoUKsnPj53f5widfln7pM9FjR4QiSYaSyB Q5DA== X-Received: by 10.182.60.168 with SMTP id i8mr5249797obr.81.1444323590444; Thu, 08 Oct 2015 09:59:50 -0700 (PDT) Original-Received: by 10.202.172.205 with HTTP; Thu, 8 Oct 2015 09:59:11 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x Xref: news.gmane.org gmane.emacs.bugs:107454 Archived-At: --089e0153716c8cc04405219aca8b Content-Type: text/plain; charset=UTF-8 >>> Eli Zaretskii > No, there was no decision yet to start the feature freeze. In that case, here is my feedback on a quick review. >>> Jay Belanger > With the patch, if the yanked number already has the radix prefix, there > is an error. It might make more sense to have Calc do an appropriate > conversion. I did not try that case as I meant to use the prefix only when the copied number does not have a calc-style prefix. But that's a valid point. If the copied number has calc-style prefix, what should have a higher priority? - The radix translated by the copied number with prefix, or - The radix conveyed by the user specified prefix to calc-yank? I believe that if the user has intentionally used the prefix, the calc-yank prefix should override. Either way, it will be easy with some string manipulation. > Also, the number of radixes in the patch is less than Calc allows. I assumed the use cases of only the common radixes used in programming. How about I display a prompt for the user to enter any radix they like (I believe calc supports up to radix 36) if the prefix is specifically '(4) ( a list prefix created when user uses C-u specifically for prefix). So now, C-2 C-y will prefix the yanked number with "2#". But C-u C-y will show a prompt where the user will enter radix. If the user entered 9, the prefix appended will be "9#". Does this option sound fair? > It might make more sense to have calc-yank use the current Calc's current radix rather than a prefix radix. I need some clarification for this point. Did you mean that if the user has set the calc radix to hex by using "d6" and now if they yank a number "1000" it gets yanked automatically as "16#1000". If yes, I believe it will cause a huge disturbance in the way people might have already got used to yanking in calc. > I don't recall the policy on using cl- functions, but cond could easily be used instead of cl-case. I personally find cl-case syntax very concise and so I used that. In a thread in emacs-devel, there is/was a discussion on if cl-lib should be preloaded automatically. I believe that until that decision is reached, I should use cond instead of cl-case. -- Kaushal Modi On Thu, Oct 8, 2015 at 12:19 PM, Kaushal Modi wrote: > Thanks for the review! > > I will work out these kinks by the time we can add in more features. > I'll update this thread then. > > > -- > Kaushal Modi > > On Thu, Oct 8, 2015 at 12:08 PM, Jay Belanger > wrote: > >> >> Hi Kaushal, >> >> > I read this question of emacs.stackexchange >> > ( http://emacs.stackexchange.com/q/13451/115) >> > where the user needed to specify the radix of the number he was >> > pasting in calc. >> > >> > If the calc default radix is decimal and if a user pastes 1000, it >> > will be pasted as decimal 1000. But what if the user meant to paste >> > binary 1000 (decimal 8)? >> > >> > My patch below enables doing that using numeric prefixes. >> > >> > Please advise if merging this patch to calc-yank is a good idea or if >> > needs improvement/bug fixes before the merging. >> >> There's a feature freeze on right now, so it shouldn't be added to Emacs >> right away. But it looks useful. >> >> With the patch, if the yanked number already has the radix prefix, there >> is an error. It might make more sense to have Calc do an appropriate >> conversion. Also, the number of radixes in the patch is less than Calc >> allows. >> It might make more sense to have calc-yank use the current Calc's >> current radix rather than a prefix radix. >> I don't recall the policy on using cl- functions, but cond could >> easily be used instead of cl-case. >> >> But this should be brought up again after the feature freeze. >> >> Jay >> >> > --089e0153716c8cc04405219aca8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>> Eli Zaretskii
=
> No, there was no decision yet to start the feature freeze= .

<= span style=3D"font-family:arial,sans-serif;font-size:12.8px">In that case, = here is my feedback on a quick review.

=
>>= ;> Jay Belanger
>= ; With the patch, if the yanked number already has the radix prefix, there<= /span>
> is an error.=C2= =A0 It might make more sense to have Calc do an appropriate
> conversion.=C2=A0
I did not try t= hat case as I meant to use the prefix only when the copied number does not = have a calc-style prefix. But that's a valid point. If the copied numbe= r has calc-style prefix, what should have a higher priority?
- The radix tra= nslated by the copied number with prefix, or
- The radix conveyed by the use= r specified prefix to calc-yank?
<= span style=3D"font-size:12.8px">I believe that if the user has intentionall= y used the prefix, the calc-yank prefix should override. Either way, it wil= l be easy with some string manipulation.

> Also, the number of radixes in the patch is= less than Calc allows.
I assumed = the use cases of only the common radixes used in programming. How about I d= isplay a prompt for the user to enter any radix they like (I believe calc s= upports up to radix 36) if the prefix is specifically '(4) ( a list pre= fix created when user uses C-u specifically for prefix).

So now, C-2 C-y will= prefix the yanked number with "2#". But C-u C-y will show a prom= pt where the user will enter radix. If the user entered 9, the prefix appen= ded will be "9#". Does this option sound fair?

> It might make more sense= to have calc-yank use the current Calc's=C2=A0current radix rather than a pr= efix radix.
I need some clarification for this point. Did you = mean that if the user has set the calc radix to hex by using "d6"= and now if they yank a number "1000" it gets yanked automaticall= y as "16#1000". If yes, I believe it will cause a huge disturbanc= e in the way people might have already got used to yanking in calc.=C2=A0

> I don'= t recall the policy on using cl- functions, but cond could=C2=A0easily be used in= stead of cl-case.
I personally find cl-case syntax very concise and so I used that. = In a thread in emacs-devel, there is/was a discussion on if cl-lib should b= e preloaded automatically. I believe that until that decision is reached, I= should use cond instead of cl-case.

--
Kaushal Modi

On Thu, Oct 8, 2015 at 12:19 PM, Kaushal Mod= i <kaushal.modi@gmail.com> wrote:
=
Thanks for the review!

I will work out t= hese kinks by the time we can add in more features.
I'll update this thread then.


--
Kaushal Modi

On Thu, Oct 8, 2015 at 12:08 PM, Jay Belange= r <jay.p.belanger@gmail.com> wrote:

Hi Kaushal,

> I read this question of emacs.stackexchange
> ( http://emacs.stackexchange.com/q/13451/115)
> where the user needed to specify the radix of the number he was
> pasting in calc.
>
> If the calc default radix is decimal and if a user pastes 1000, it
> will be pasted as decimal 1000. But what if the user meant to paste > binary 1000 (decimal 8)?
>
> My patch below enables doing that using numeric prefixes.
>
> Please advise if merging this patch to calc-yank is a good idea or if<= br> > needs improvement/bug fixes before the merging.

There's a feature freeze on right now, so it shouldn't be ad= ded to Emacs
right away.=C2=A0 But it looks useful.

With the patch, if the yanked number already has the radix prefix, there is an error.=C2=A0 It might make more sense to have Calc do an appropriate<= br> conversion. Also, the number of radixes in the patch is less than Calc allo= ws.
It might make more sense to have calc-yank use the current Calc's
current radix rather than a prefix radix.
I don't recall the policy on using cl- functions, but cond could
easily be used instead of cl-case.

But this should be brought up again after the feature freeze.

Jay



--089e0153716c8cc04405219aca8b--