From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xi Shen Subject: Re: [PATCH] ob-sql.el: Support sqlcmd and cygwin environment Date: Sun, 12 Jun 2016 02:12:46 +0000 Message-ID: References: <87r3c4em1r.fsf@saiph.selenimh> <87a8isdso8.fsf@saiph.selenimh> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ad4c2539e6005350b4ff3 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bButX-0004ep-Tu for Emacs-orgmode@gnu.org; Sat, 11 Jun 2016 22:13:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bButV-0005vQ-20 for Emacs-orgmode@gnu.org; Sat, 11 Jun 2016 22:12:58 -0400 Received: from mail-oi0-x22b.google.com ([2607:f8b0:4003:c06::22b]:34873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bButU-0005tr-RG for Emacs-orgmode@gnu.org; Sat, 11 Jun 2016 22:12:56 -0400 Received: by mail-oi0-x22b.google.com with SMTP id w5so85002282oib.2 for ; Sat, 11 Jun 2016 19:12:55 -0700 (PDT) In-Reply-To: <87a8isdso8.fsf@saiph.selenimh> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: "Emacs-orgmode@gnu.org" --001a113ad4c2539e6005350b4ff3 Content-Type: text/plain; charset=UTF-8 Yes, I think it is better to let upstream function to resolve the path for org-mode. But I have never contacted Emacs developers before. Should I go through the bug-gnu-emacs@gnu.org mail list? Or there's a more effective channel? On Sat, Jun 11, 2016 at 4:41 PM Nicolas Goaziou wrote: > Hello, > > Xi Shen writes: > > > According to > > > https://www.gnu.org/software/emacs/manual/html_node/elisp/Standard-File-Names.html > , > > the `convert-standard-filename` works for *nix and MS-DOS, but not Cygwin > > environment. And I tested, it does not work. For the prefix, please > advice > > me a better one. Maybe we should path this function first? How can I > > patch/update a Emacs native function? > > Since there is no module in Emacs, you need to prefix functions and > variables according to the package, or, even better, the library they > belong to. > > Hence, functions and variables in "ob-sql.el" are prefixed with > "org-babel-sql-". > > Do you mind discussing it upstream on emacs-devel ML first? I don't > think this kind of function belongs to Org. If upstream has no > equivalent and doesn't want to add one, we might consider adding it to > the library. > > WDYT? > > >> > The `osql` command line tool was last updated in 2004, > >> > https://technet.microsoft.com/en-us/library/aa214012(v=sql.80).aspx, > >> > and could not output the query result in a way that morden > >> > `org-table.el` expects. The `sqlcmd` is the preferred command line > >> > tool to connect the Microsoft SQL Server and it also has a Linux > >> > version, > >> > https://msdn.microsoft.com/en-us/library/hh568447(v=sql.110).aspx. > >> > >> Would it make sense to remove the msosql support then? > >> > > Yes, but I am also thinking about backward compatibility. Do you want > > me to create a patch to remove `msosql` support? > > AFAIU, according to your comment, "osql" output is barely usable. If you > think it is still usable and even used by some users, then I do not mind > keeping it. I just wanted to be sure we're not keeping something that is > not reasonable to keep. > > >> #'identity > >> > >> > >>> OK, but what's the difference? Care to give me a short lesson? > >>>Thanks! > > Not much difference, hence the "nitpick" tag. > > 'identity is a generic symbol, #'identity clearly indicates we (the > user, the compiler) are interested in the symbol function cell. > > In this case, it is obvious, but it is not always the case in other > parts of the code base, and more consistency in the right direction > doesn't hurt. > > > Regards, > > -- > Nicolas Goaziou > > Thanks, David -- Thanks, David S. --001a113ad4c2539e6005350b4ff3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I think it is better to let upstream function to reso= lve the path for org-mode.

But I have never contacted Em= acs developers before. Should I go through the=C2=A0bug-gnu-e= macs@gnu.org=C2=A0mail list? Or there's a more effective channel?


On Sat, Jun 11, 2016 at 4:41 PM Nicolas Goaz= iou <mail@ni= colasgoaziou.fr> wrote:
Hell= o,

Xi Shen <davi= dshen84@gmail.com> writes:

> According to
> https://www.g= nu.org/software/emacs/manual/html_node/elisp/Standard-File-Names.html,<= br> > the `convert-standard-filename` works for *nix and MS-DOS, but not Cyg= win
> environment. And I tested, it does not work. For the prefix, please ad= vice
> me a better one. Maybe we should path this function first? How can I > patch/update a Emacs native function?

Since there is no module in Emacs, you need to prefix functions and
variables according to the package, or, even better, the library they
belong to.

Hence, functions and variables in "ob-sql.el" are prefixed with "org-babel-sql-".

Do you mind discussing it upstream on emacs-devel ML first? I don't
think this kind of function belongs to Org. If upstream has no
equivalent and doesn't want to add one, we might consider adding it to<= br> the library.

WDYT?

>> > The `osql` command line tool was last updated in 2004,
>> > https://technet.m= icrosoft.com/en-us/library/aa214012(v=3Dsql.80).aspx,
>> > and could not output the query result in a way that morden >> > `org-table.el` expects.=C2=A0 The `sqlcmd` is the preferred c= ommand line
>> > tool to connect the Microsoft SQL Server and it also has a Li= nux
>> > version,
>> > https://msdn.micros= oft.com/en-us/library/hh568447(v=3Dsql.110).aspx.
>>
>> Would it make sense to remove the msosql support then?
>>
> Yes, but I am also thinking about backward compatibility. Do you want<= br> > me to create a patch to remove `msosql` support?

AFAIU, according to your comment, "osql" output is barely usable.= If you
think it is still usable and even used by some users, then I do not mind keeping it. I just wanted to be sure we're not keeping something that i= s
not reasonable to keep.

>> #'identity
>>
>>
>>> OK, but what's the difference? Care to give me a short les= son?
>>>Thanks!

Not much difference, hence the "nitpick" tag.

'identity is a generic symbol, #'identity clearly indicates we (the=
user, the compiler) are interested in the symbol function cell.

In this case, it is obvious, but it is not always the case in other
parts of the code base, and more consistency in the right direction
doesn't hurt.


Regards,

--
Nicolas Goaziou



Thanks,
David
=C2=A0
--

Thanks, David S.

--001a113ad4c2539e6005350b4ff3--