Menu
▾
▴
gnuplot-beta
|
From: Jonathan O. <j.j...@gm...> - 2012-02-08 23:43:09
|
Hi Gnuplot developers,
I've been working on an add-on module for Bruce Ravel's Emacs
gnuplot-mode, to add context-sensitive completion and documentation
lookup for Gnuplot script buffers. It does a fairly complete parse of
the Gnuplot language so it should hopefully be quite useful once I
finish writing the rest of the grammar rules.
I'd like to release this sometime soon and my question has to do with
licensing. I would like my Elisp code to be GPL'ed (in fact it
probably has to be since it extends gnuplot.el, which is
GPL'ed). However, it has the ability to show short documentation
strings ("ElDoc") to display in the mode line depending on what's at
point, and the easiest way of getting these would be to copy them out
of the Gnuplot info manual. I know Gnuplot itself is not under the GPL
and so I'm not sure whether this would be against its license terms.
Could anyone tell me whether this would be considered acceptable use?
Thanks,
Jonathan
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-02-09 06:40:34
|
On Wednesday, 08 February 2012, Jonathan Oddie wrote:
> Hi Gnuplot developers,
>
> I've been working on an add-on module for Bruce Ravel's Emacs
> gnuplot-mode, to add context-sensitive completion and documentation
> lookup for Gnuplot script buffers. It does a fairly complete parse of
> the Gnuplot language so it should hopefully be quite useful once I
> finish writing the rest of the grammar rules.
>
> I'd like to release this sometime soon and my question has to do with
> licensing. I would like my Elisp code to be GPL'ed (in fact it
> probably has to be since it extends gnuplot.el, which is
> GPL'ed). However, it has the ability to show short documentation
> strings ("ElDoc") to display in the mode line depending on what's at
> point, and the easiest way of getting these would be to copy them out
> of the Gnuplot info manual. I know Gnuplot itself is not under the GPL
> and so I'm not sure whether this would be against its license terms.
>
> Could anyone tell me whether this would be considered acceptable use?
I don't understand the intended mechanism.
Are you saying that this new code would act as a viewer for the
existing documentation? That would not introduce any licensing issues
that I can think of. You can use any viewer you like. I'm sure
some people use the Acrobat reader to view the PDF documentation,
for instance, and Acrobat certainly isn't under the gnuplot license.
If you're saying that you want to maintain a new, parallel, set of
documentation, I think that's a bad idea. It would be far too much
trouble to keep it in sync.
Ethan
>
> Thanks,
> Jonathan
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
|
|
From: Jonathan O. <j.j...@gm...> - 2012-02-09 09:55:15
|
Hi Ethan,
>>
>> Could anyone tell me whether this would be considered acceptable use?
>
> I don't understand the intended mechanism.
>
Sorry I wasn't clear. No, I'm not intending to maintain a separate set
of documentation. (I use the info viewer inside Emacs for reading
that, and the code I'm working on creates links to it from the source
buffer). What I'm thinking of are more like what are called "tooltips"
in other environments. In other Emacs language modes (C, Lisp, etc.)
you can have the editor show a one-line message at the bottom of the
screen listing the arguments to a function as soon as you type it or
move the cursor over it, and this saves looking up the full
manual. E.g. when the cursor is after "smooth" Emacs displays
smooth {unique | frequency | cumulative | kdensity ... }
or something similar. Or after typing "using" in a plot command with a
particular plot style it lists the order of columns expected. I find
this quite useful as I often forget the order of arguments to some
options.
I guess this is a maintenance concern to an extent since the
documentation strings would be in the Elisp source (they can't really
be extracted automatically from the info page, as far as I can see). I
think the benefit might outweigh the cost. What do you think? If
people aren't convinced I'll leave it out and just have the completion
code + links to the info manual.
Jonathan
>
> If you're saying that you want to maintain a new, parallel, set of
> documentation, I think that's a bad idea. It would be far too much
> trouble to keep it in sync.
>
> Ethan
>
>
>>
>> Thanks,
>> Jonathan
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-02-09 16:23:02
|
On Thursday, 09 February 2012, Jonathan Oddie wrote:
>
> Hi Ethan,
>
> >>
> >> Could anyone tell me whether this would be considered acceptable use?
> >
> > I don't understand the intended mechanism.
> >
>
> Sorry I wasn't clear. No, I'm not intending to maintain a separate set
> of documentation. (I use the info viewer inside Emacs for reading
> that, and the code I'm working on creates links to it from the source
> buffer). What I'm thinking of are more like what are called "tooltips"
> in other environments. In other Emacs language modes (C, Lisp, etc.)
> you can have the editor show a one-line message at the bottom of the
> screen listing the arguments to a function as soon as you type it or
> move the cursor over it, and this saves looking up the full
> manual. E.g. when the cursor is after "smooth" Emacs displays
>
> smooth {unique | frequency | cumulative | kdensity ... }
>
> or something similar. Or after typing "using" in a plot command with a
> particular plot style it lists the order of columns expected. I find
> this quite useful as I often forget the order of arguments to some
> options.
>
> I guess this is a maintenance concern to an extent since the
> documentation strings would be in the Elisp source (they can't really
> be extracted automatically from the info page, as far as I can see). I
> think the benefit might outweigh the cost. What do you think?
>
> Jonathan
Ugh. Not from the info page. Does anyone really use that?
I'd say the better method would be to write a quick doc2tooltip.c
program to parallel the others. It would look for the string
Syntax:
in gnuplot.doc and extract the following lines into a tooltip
collection.
Probably there are some commands that don't have this keyword
in the current *.doc file, but it seems reasonable to standardize
them if it helps a real-world use.
Ethan
|
|
From: Jonathan O. <j.j...@gm...> - 2012-02-09 17:29:41
|
> > I'd say the better method would be to write a quick doc2tooltip.c > program to parallel the others. It would look for the string > Syntax: > in gnuplot.doc and extract the following lines into a tooltip > collection. Indeed, that's a better idea; thanks for the suggestion. Now that I look at the docs/ directory I see there is already a `doc2texi.el' contributed by Bruce Ravel, the author of gnuplot-mode. It would probably make the most sense for me to modify that to output an Elisp file of tooltips along with the texinfo file. Any objections? I would hope that would also nullify the license conflict problem, but someone correct me if I'm wrong. > Probably there are some commands that don't have this keyword > in the current *.doc file, but it seems reasonable to standardize > them if it helps a real-world use. I agree -- if anyone uses this enough to be annoyed by its limitations in the future, it can be addressed then. Jonathan |
|
From: Ethan A M. <sf...@us...> - 2012-02-09 17:52:12
|
> > > > I'd say the better method would be to write a quick doc2tooltip.c > > program to parallel the others. It would look for the string > > Syntax: > > in gnuplot.doc and extract the following lines into a tooltip > > collection. > > > Indeed, that's a better idea; thanks for the suggestion. Now that I > look at the docs/ directory I see there is already a `doc2texi.el' > contributed by Bruce Ravel, the author of gnuplot-mode. It would > probably make the most sense for me to modify that to output an Elisp > file of tooltips along with the texinfo file. Any objections? No objections. Just a warning that the code in doc2texi.el may itself be a bit rusty. I seem to recall some reports of problems with the *.info file involving infinite loops of redirected links or something like that. Ethan |
|
From: Jon O. <j.j...@gm...> - 2012-04-25 23:50:49
|
Hi all, A couple of months ago I wrote about wanting to support quick contextual documentation in Emacs' gnuplot-mode, then let it drop as I was busy with other things. It's working now and I've submitted two patches for doc2texi.el to the tracker: 3521460 patches doc2texi to additionally create an Elisp file of ElDoc strings (Emacs' version of tooltips) extracted from the Syntax: descriptions in gnuplot.doc. It also compiles it and installs it in the site-lisp directory. The generated file includes a copy of the Gnuplot license at the top along with a disclaimer that it is auto-generated and not meant to be edited by hand. 3521457 fixes a couple of minor bugs (avoiding inserting multiple copies of the same terminal help, which sometimes happened before) There's probably little point in merging these unless/until the corresponding pieces are merged in a new release of gnuplot-mode, but I wanted to put them out there. If there are any interested Emacs users on this list they can check out the `context' branch of gnuplot-mode at https://github.com/bruceravel/gnuplot-mode/tree/context and see if it works for them. I also wanted to ask if it would be OK in the meantime to include a copy of either (a) the auto-generated 'gnuplot-eldoc.el' strings file or (b) the patched doc2texi.el, in the gnuplot-mode repository. Thanks, Jon On 9 Feb 2012, at 18:50, Ethan A Merritt wrote: >>> >>> I'd say the better method would be to write a quick doc2tooltip.c >>> program to parallel the others. It would look for the string >>> Syntax: >>> in gnuplot.doc and extract the following lines into a tooltip >>> collection. >> >> >> Indeed, that's a better idea; thanks for the suggestion. Now that I >> look at the docs/ directory I see there is already a `doc2texi.el' >> contributed by Bruce Ravel, the author of gnuplot-mode. It would >> probably make the most sense for me to modify that to output an Elisp >> file of tooltips along with the texinfo file. Any objections? > > No objections. Just a warning that the code in doc2texi.el may itself > be a bit rusty. I seem to recall some reports of problems with the > *.info file involving infinite loops of redirected links or something > like that. > > Ethan |
|
From: Ethan M. <merritt@u.washington.edu> - 2012-04-26 03:16:09
|
On Wednesday, 25 April 2012, Jon Oddie wrote: > > 3521460 patches doc2texi to additionally create an Elisp file of ElDoc > strings (Emacs' version of tooltips) extracted from the Syntax: > > 3521457 fixes a couple of minor bugs (avoiding inserting multiple > copies of the same terminal help, which sometimes happened before) > > There's probably little point in merging these unless/until the > corresponding pieces are merged in a new release of gnuplot-mode When you say "little point in merging", does that mean it's harmless or does it mean it will break something for people not using an updated gnuplot-mode? Harmless looking back but useful going forward is fine. Broken until you upgrade is not. Ethan > , but > I wanted to put them out there. If there are any interested Emacs > users on this list they can check out the `context' branch of > gnuplot-mode at > https://github.com/bruceravel/gnuplot-mode/tree/context and see if it > works for them. > > I also wanted to ask if it would be OK in the meantime to include a > copy of either (a) the auto-generated 'gnuplot-eldoc.el' strings file > or (b) the patched doc2texi.el, in the gnuplot-mode repository. > > Thanks, > > Jon > > > > > On 9 Feb 2012, at 18:50, Ethan A Merritt wrote: > > >>> > >>> I'd say the better method would be to write a quick doc2tooltip.c > >>> program to parallel the others. It would look for the string > >>> Syntax: > >>> in gnuplot.doc and extract the following lines into a tooltip > >>> collection. > >> > >> > >> Indeed, that's a better idea; thanks for the suggestion. Now that I > >> look at the docs/ directory I see there is already a `doc2texi.el' > >> contributed by Bruce Ravel, the author of gnuplot-mode. It would > >> probably make the most sense for me to modify that to output an Elisp > >> file of tooltips along with the texinfo file. Any objections? > > > > No objections. Just a warning that the code in doc2texi.el may itself > > be a bit rusty. I seem to recall some reports of problems with the > > *.info file involving infinite loops of redirected links or something > > like that. > > > > Ethan > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Jonathan O. <j.j...@gm...> - 2012-04-26 09:14:59
|
>> >> There's probably little point in merging these unless/until the >> corresponding pieces are merged in a new release of gnuplot-mode > > When you say "little point in merging", does that mean it's harmless > or does it mean it will break something for people not using an > updated gnuplot-mode? Harmless looking back but useful going > forward is fine. Broken until you upgrade is not. It's harmless. All it will do is create two unused Lisp files, which are only loaded into Emacs if someone has the patched gnuplot-mode. The other patch just eliminates some duplicate pages in the Info file. (I confirmed this by diffing the output of the original and the patched version). |
|
From: Ethan A M. <sf...@us...> - 2012-04-26 17:04:24
|
On Thursday, April 26, 2012 02:14:46 am Jonathan Oddie wrote:
>
> The other patch just eliminates some duplicate pages in the Info
> file. (I confirmed this by diffing the output of the original and
> the patched version).
>
OK, but there seems to be a problem.
After applying that patch, the build script no longer works here:
[343] patch -p1 < ../../doc2texi-bugfix-patch.diff
patching file doc2texi.el
[344] make gnuplot.texi
Creating texinfo
Loading /etc/emacs/site-start.d/autoconf.el (source)...
Loading /etc/emacs/site-start.d/cmake.el (source)...
Loading /etc/emacs/site-start.d/desktop-file-utils.el (source)...
Loading /etc/emacs/site-start.d/gettext.el (source)...
Loading /etc/emacs/site-start.d/python.el (source)...
Loading /etc/emacs/site-start.d/rpm-mandriva-setup.el (source)...
Loading /etc/emacs/site-start.d/rst.el (source)...
Loading /etc/emacs/site-start.d/ruby.el (source)...
Loading /etc/emacs/site-start.d/vc_git.el (source)...
Inserting help for terminals ...
Wrong type argument: stringp, ("linux")
make: *** [gnuplot.texi] Error 255
[345] emacs --version
GNU Emacs 23.1.1
|
|
From: Mojca M. <moj...@gm...> - 2012-04-26 09:32:14
|
It is not exactly about the topic at hand (I'm not emacs user and know even less about lisp), but there were three bug reports in macports about misconfigured emacs support (not necessary related to bad configuration in gnuplot itself). The main problem is that gnuplot package doesn't depend on emacs (but that can easily be fixed in macports), the second problem reported reported is that gnuplot sometimes uses some random emacs present on computer and may fail to install. If there is some volunteer (pointing at Jonathar, but there might be others) willing to explain me what exactly has to be done, how to make sure that exactly the specified version of emacs is used, whether it makes sense to create a separate package "gnuplot-emacs" that only installs the list files to the desired place etc. ... please let me know. Mojca |
|
From: Jon O. <j.j...@gm...> - 2012-04-26 11:26:50
|
Hi Mojca, I have both Macports and several versions of Emacs scattered about so I'd be happy to help if I can. Can you point me to the bug reports? Jon On 26 Apr 2012, at 10:32, Mojca Miklavec wrote: > It is not exactly about the topic at hand (I'm not emacs user and know > even less about lisp), but there were three bug reports in macports > about misconfigured emacs support (not necessary related to bad > configuration in gnuplot itself). > > The main problem is that gnuplot package doesn't depend on emacs (but > that can easily be fixed in macports), the second problem reported > reported is that gnuplot sometimes uses some random emacs present on > computer and may fail to install. > > If there is some volunteer (pointing at Jonathar, but there might be > others) willing to explain me what exactly has to be done, how to make > sure that exactly the specified version of emacs is used, whether it > makes sense to create a separate package "gnuplot-emacs" that only > installs the list files to the desired place etc. ... please let me > know. > > Mojca |
