gnuplot-info — For questions and discussion about gnuplot

[Gnuplot-info] Set title using datafile

[Mátyás S. <ser...@gm...>]

Hi all,

I have a problem with setting the title for a diagram made with gnuplot. I
would like to import the first line of the datafile as a string, and write
it above the diagram, as a title. Then the numerical data can be plotted.
How can I do it?
Could you please help me? I attached a sample datafile for illustration.

Thanks,

Mat

Re: [Gnuplot-info] "set key noautotitle" ignored on explicit column name?

[Rhys U. <rhy...@gm...>]

> Apart from the question of whether a new or modified variant of
> "set key autotitle" is warranted, I suggest that for plotting
> 30 files with column 'x' an appropriate set of commands is
>
>   LIST = "file1 file2 file3 .... file30"
>   plot for [NAME in LIST] NAME.".dat" using 0:"x" title NAME

Understood.

That recipe still runs afoul of the
    LIST = "file1 file2 file3 .... file30"
    plot for [NAME in LIST] NAME.".dat" using 0:"x" title NAME.' using 0:"x"'
issue, especially with computed column names, that I mentioned in my
response to Hans.

I really do want to label with the entire {"<datafile>"
{datafile-modifiers}}} handed to the plot command.

Thanks for everyone's time,
Rhys

Re: [Gnuplot-info] "set key noautotitle" ignored on explicit column name?

[Rhys U. <rhy...@gm...>]

>> plot 'foo.dat' using 0:"x", 'bar.dat' using 0:"x"
> So bite the bullet and _tell_ it what title you want.

plot 'foo' using 0:'x' title "'foo' using 0:'x'", \
      'bar' using 0:'x' title "'bar' using 0:'x'"

Bleeeech.  Now, consider the possibility of complicated computed columns...

> There's always a limit to the possible success of tools trying to read people's mind.  If they fail, just tell them what to do.

Agreed.  But before jumping through the hoops in the foo/bar with
title example just above, I'd much prefer to turn off the tools'
mindreading tendencies.  Hence my original note.

- Rhys

Re: [Gnuplot-info] "set key noautotitle" ignored on explicit column name?

[Ethan A M. <eam...@gm...>]

On Wednesday, 12 March 2014 11:05:50 PM Rhys Ulerich wrote:
> Hi Ethan,
> 
> Thanks for taking a look and the time to respond.
> 
> > Because in the 4th plots you tell it to read the columnheader
> > (in order to find column "x") and so the input data must necessarily
> > _have_ columnheaders.  That is the same thing that
> > you are telling it with "set key autotitle columnheader".
> > Same request - same result.
> >
> > Therefore plot #4 shows the intended behaviour.
> 
> I have a use case where that behavior becomes a decided usability hiccup.
> 
> set key autotitle
> plot 'foo.dat' using 0:"x", 'bar.dat' using 0:"x"
> 
> Now I have two autotitled legend entries that uselessly both say "x".
> I can't tell them apart.  The file name is the only distinguishing
> feature and using "x" suppresses the filenames' appearance.  I
> implicitly didn't ask for column headers because I omitted
> "columnheader" when turning on autotitling.  I can't turn this
> behavior off because there's no "set key autotitle nocolumnheader".
> 
> The usability hiccup becomes worse as the number of files involved and
> number of columns increase.  I'm somewhere in the 30+ files and 200+
> column range on a daily basis.
> - Rhys

Apart from the question of whether a new or modified variant of
"set key autotitle" is warranted, I suggest that for plotting 
30 files with column 'x' an appropriate set of commands is

  LIST = "file1 file2 file3 .... file30"
  plot for [NAME in LIST] NAME.".dat" using 0:"x" title NAME

		Ethan 

[Gnuplot-info] histeps fillsteps

[Michael S. <mic...@me...>]

Hello,

is there a way to fill the space below a "histeps" curve like the style "fillsteps" does it for a "steps"-like curve?

Best regards,
Michael

Re: [Gnuplot-info] "set key noautotitle" ignored on explicit column name?

[Hans-Bernhard B. <HBB...@t-...>]

On 13.03.2014 05:05, Rhys Ulerich wrote:
> I have a use case where that behavior becomes a decided usability hiccup.
>
> set key autotitle
> plot 'foo.dat' using 0:"x", 'bar.dat' using 0:"x"
>
> Now I have two autotitled legend entries that uselessly both say "x".
> I can't tell them apart.

So bite the bullet and _tell_ it what title you want.

There's always a limit to the possible success of tools trying to read 
people's mind.  If they fail, just tell them what to do.

Re: [Gnuplot-info] "set key noautotitle" ignored on explicit column name?

[Rhys U. <rhy...@gm...>]

Hi Ethan,

Thanks for taking a look and the time to respond.

> Because in the 4th plots you tell it to read the columnheader
> (in order to find column "x") and so the input data must necessarily
> _have_ columnheaders.  That is the same thing that
> you are telling it with "set key autotitle columnheader".
> Same request - same result.
>
> Therefore plot #4 shows the intended behaviour.

I have a use case where that behavior becomes a decided usability hiccup.

set key autotitle
plot 'foo.dat' using 0:"x", 'bar.dat' using 0:"x"

Now I have two autotitled legend entries that uselessly both say "x".
I can't tell them apart.  The file name is the only distinguishing
feature and using "x" suppresses the filenames' appearance.  I
implicitly didn't ask for column headers because I omitted
"columnheader" when turning on autotitling.  I can't turn this
behavior off because there's no "set key autotitle nocolumnheader".

The usability hiccup becomes worse as the number of files involved and
number of columns increase.  I'm somewhere in the 30+ files and 200+
column range on a daily basis.

> If your column header were "3rd_base" or something
> like that, plot commands #1 would produce an incorrect plot
> with a spurious initial data point at 3.

I personally make my column headers to be valid C identifiers (so
"third_base" not "3rd_base") deliberately so that skipping the first
invalid line is makes "using 0:1" perfectly well-behaved.

> Plot #2 is arguably a demonstration that we should have two
> distinct commands that don't really exist yet:
>    set noautotitle columnheader
>   set autotitle nocolumnheader

How about just the current three with the middle one amended to fix
the usability hiccup I described?

set key noautotitle: no autotitles, period
set key autotitle: autotitles from plot specifier without magical
columnheader behavior that wasn't requested
set key autotitle columnheader: autotitles with magical columnheaders

Otherwise you'll have to explain that
    set key noautotitle nocolumnheader
doesn't really mean
    set key autotitle columnheader
on account of the double negative.

All that said, hell of a tool.  Thank you for the effort you put into it.

- Rhys

Re: [Gnuplot-info] "set key noautotitle" ignored on explicit column name?

[Ethan A M. <eam...@gm...>]

On Wednesday, 12 March 2014 01:21:36 PM Rhys Ulerich wrote:
> Why does the first plot below obey "set key noautotitle" while the
> second one ignores it?
> 
> $ gnuplot -V
> gnuplot 4.6 patchlevel 5
> 
> $ file ~/.gnuplot  # No rcfile magic up my sleeve
> /h2/rhys/.gnuplot: cannot open `/h2/rhys/.gnuplot' (No such file or directory)
> 
> $ cat data
> x
> 1
> 2
> 3
> 
> $ gnuplot
> gnuplot> set key noautotitle
> gnuplot> plot 'data' using 0:1    # First
> gnuplot> plot 'data' using 0:"x"  # Second
> gnuplot> set key autotitle
> gnuplot> plot 'data' using 0:1    # Third
> gnuplot> plot 'data' using 0:"x"  # Fourth
> 
> Why does this third plot autotitle "correctly" from the plot
> specification while the fourth behaves as if I said "set key autotitle
> columnheader"?

Because in the 4th plots you tell it to read the columnheader
(in order to find column "x") and so the input data must necessarily
_have_ columnheaders.  That is the same thing that 
you are telling it with "set key autotitle columnheader".
Same request - same result.

Therefore plot #4 shows the intended behaviour.

Plot #2  - maybe not.
 
On the other hand, plot command #1 is just wrong.
You luck out because the column header happens to be
a string that cannot be parsed as valid numeric input,
so the first line is treated as containing an undefined/missing
data value.   If your column header were "3rd_base" or something
like that, plot commands #1 would produce an incorrect plot
with a spurious initial data point at 3.

> I find the behaviors on the second and fourth plots to be buggy, but
> perhaps I'm misunderstanding something implicit about using a named
> column.
> - Rhys

I don't see anything remotely buggy about #3 or #4.
Plots #1 should probably print a warning.

Plot #2 is arguably a demonstration that we should have two
distinct commands that don't really exist yet:
   set noautotitle columnheader
   set autotitle nocolumnheader


		Ethan

[Gnuplot-info] "set key noautotitle" ignored on explicit column name?

[Rhys U. <rhy...@gm...>]

Why does the first plot below obey "set key noautotitle" while the
second one ignores it?

$ gnuplot -V
gnuplot 4.6 patchlevel 5

$ file ~/.gnuplot  # No rcfile magic up my sleeve
/h2/rhys/.gnuplot: cannot open `/h2/rhys/.gnuplot' (No such file or directory)

$ cat data
x
1
2
3

$ gnuplot
gnuplot> set key noautotitle
gnuplot> plot 'data' using 0:1    # First
gnuplot> plot 'data' using 0:"x"  # Second

Why does this third plot autotitle "correctly" from the plot
specification while the fourth behaves as if I said "set key autotitle
columnheader"?

gnuplot> set key autotitle
gnuplot> plot 'data' using 0:1    # Third
gnuplot> plot 'data' using 0:"x"  # Fourth

I find the behaviors on the second and fourth plots to be buggy, but
perhaps I'm misunderstanding something implicit about using a named
column.

- Rhys

Re: [Gnuplot-info] trendline

[Natu <inc...@rj...>]

On 03/10/2014 09:36 AM, Thomas Sefzick wrote:
> Natu <incoming-sourceforge <at> rjl.com> writes:
>> ...
>> Here's the data in test4.dat
>>
>> 03/09/14,23:59:31,61.9
>> 03/09/14,00:09:31,66.5
>> ...
> the day is wrong in the first data line,
> it should be 03/08/14
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-info

Thank You for pointing that out.  It was a bug in the program that
generated the data.  Problem solved.

Nataraj

Re: [Gnuplot-info] trendline

[Thomas S. <t.s...@fz...>]

Natu <incoming-sourceforge <at> rjl.com> writes:
> ...
> Here's the data in test4.dat
> 
> 03/09/14,23:59:31,61.9
> 03/09/14,00:09:31,66.5
> ...

the day is wrong in the first data line,
it should be 03/08/14

Re: [Gnuplot-info] trendline

[Natu <inc...@rj...>]

On 03/10/2014 05:05 AM, Hans-Bernhard Bröker wrote:
> On 10.03.2014 01:03, Natu wrote:
>
>>      set multiplot
>>      plot "GKLOG001_25452.AVG" using 1:7 with linespoints title "\n5
>> minute min/avg/max" lt rgb "blue";
>>      plot "GKLOG001_25452.MIN" using 1:7 with linespoints title "" lt
>> rgb
>> "green";
>>      plot "GKLOG001_25452.MAX" using 1:7 with linespoints title "" lt
>> rgb
>> "red";
>
> This use of 'multiplot' is ill-advised.  It will not have any positive
> effect compared to a more straight-forward
>
>       plot "GKLOG001_25452.AVG" u 1:7 w lp t "avg" lt rgb "blue", \
>          "GKLOG001_25452.MIN" u 1:7 w lp t"min" lt rgb "green", \
>         "GKLOG001_25452.MAX" u 1:7 wlp t "max" lt rgb "red"
>
>> When I plot certain data files, gnuplot draws a line across the graph
>> showing the increasing/decreasing trend of the data.
>
> I'm reasonably sure this has nothing to do with any trend.  But it's
> hard to know what else it might be, because you don't show any data
> that triggered it.
>

Thank you for all the replies.  Most seemed to think that it was related
to the multiplot.  I have created a very simple example with no
multiplot.  Here are the commands and data that produced this.  I am
running gnuplot 4.4 patchlevel 3 under ubuntu 12.04.  Same problem under
gnuplot 4.2.  I was a little unsure about parsing the date/time from two
columns, but I got that from several web page examples.  It seems to
work correctly.

    set datafile separator ","
    set xdata time
    set timefmt "%m/%d/%y,%H:%M:%S"
    set format x "%H:%M\n%m/%d"
    plot "test4.dat" using 1:3 with linespoints;

Here's the data in test4.dat

03/09/14,23:59:31,61.9
03/09/14,00:09:31,66.5
03/09/14,00:19:31,65.1
03/09/14,00:29:31,66.4
03/09/14,00:39:31,67.6
03/09/14,00:49:31,63.1
03/09/14,00:59:31,62.4
03/09/14,01:09:31,61.3
03/09/14,01:19:31,61.2
03/09/14,01:29:31,68.8
03/09/14,01:39:31,59.8
03/09/14,01:49:31,65.5
03/09/14,01:59:31,61.5
03/09/14,02:09:31,67.2
03/09/14,02:19:31,63.9
03/09/14,02:29:31,65.1
03/09/14,02:39:31,60.3
03/09/14,02:49:31,64.2
03/09/14,02:59:31,59.7
03/09/14,03:09:31,59.1
03/09/14,03:19:31,61
03/09/14,03:29:31,66
03/09/14,03:39:31,63.9
03/09/14,03:49:31,60.2
03/09/14,03:59:31,61.3
03/09/14,04:09:31,63.2
03/09/14,04:19:31,64.9
03/09/14,04:29:31,66
03/09/14,04:39:31,60.5
03/09/14,04:49:31,66.3
03/09/14,04:59:31,62.3
03/09/14,05:09:31,62.3
03/09/14,05:19:31,65.2
03/09/14,05:29:31,63.5
03/09/14,05:39:31,65.2
03/09/14,05:49:31,60.8
03/09/14,05:59:31,62.1
03/09/14,06:09:31,66.6
03/09/14,06:19:31,67.9
03/09/14,06:29:31,64
03/09/14,06:39:31,62.3
03/09/14,06:49:31,62.6
03/09/14,06:59:31,62.5
03/09/14,07:09:31,61.8
03/09/14,07:19:31,60.9
03/09/14,07:29:31,62.7
03/09/14,07:39:31,59.9
03/09/14,07:49:31,59.1
03/09/14,07:59:31,62.6
03/09/14,08:09:31,65.3
03/09/14,08:19:31,58.2
03/09/14,08:29:31,60.8


Thank You,
Natu

[Gnuplot-info] Complex number...

[ckm <c_...@ya...>]

I want to do curve fitting with complex number. I just wanted to know if it
is possible because gnuplot takes complex number in many functions. 



--
View this message in context: http://gnuplot.10905.n7.nabble.com/Complex-number-tp18211.html
Sent from the Gnuplot - User mailing list archive at Nabble.com.

Re: [Gnuplot-info] trendline

[Hans-Bernhard B. <HBB...@t-...>]

On 10.03.2014 01:03, Natu wrote:

>      set multiplot
>      plot "GKLOG001_25452.AVG" using 1:7 with linespoints title "\n5
> minute min/avg/max" lt rgb "blue";
>      plot "GKLOG001_25452.MIN" using 1:7 with linespoints title "" lt rgb
> "green";
>      plot "GKLOG001_25452.MAX" using 1:7 with linespoints title "" lt rgb
> "red";

This use of 'multiplot' is ill-advised.  It will not have any positive 
effect compared to a more straight-forward

       plot "GKLOG001_25452.AVG" u 1:7 w lp t "avg" lt rgb "blue", \
          "GKLOG001_25452.MIN" u 1:7 w lp t"min" lt rgb "green", \
         "GKLOG001_25452.MAX" u 1:7 wlp t "max" lt rgb "red"

> When I plot certain data files, gnuplot draws a line across the graph
> showing the increasing/decreasing trend of the data.

I'm reasonably sure this has nothing to do with any trend.  But it's 
hard to know what else it might be, because you don't show any data that 
triggered it.

[Gnuplot-info] trendline

[Natu <inc...@rj...>]

I have a bunch of datafiles that I am plotting as follows:

    set datafile separator ","
    set xdata time
    set xlabel "time/date"
    set grid
    set timefmt "%m/%d/%y,%H:%M:%S"
    set format x "%H:%M\n%m/%d"
    set ylabel "counts"
    set yrange ["42":"91"]
    set multiplot
    plot "GKLOG001_25452.AVG" using 1:7 with linespoints title "\n5
minute min/avg/max" lt rgb "blue";
    plot "GKLOG001_25452.MIN" using 1:7 with linespoints title "" lt rgb
"green";
    plot "GKLOG001_25452.MAX" using 1:7 with linespoints title "" lt rgb
"red";

When I plot certain data files, gnuplot draws a line across the graph
showing the increasing/decreasing trend of the data.  With other data
the line does not get drawn.  I am calling this a trendline because I
don't know what else it would be called (Maybe a fit line?).  I have not
given any commands asking it to do this.

Does anyone know what this is and how it might be turned off?

Thank You,
Natu

Re: [Gnuplot-info] 'set termoption enhanced' breaks 'set term x11 persist'

[Rhys U. <rhy...@gm...>]

> Please file a bug report on the SourceForge tracker so
> we don't lose track of it

Filed as https://sourceforge.net/p/gnuplot/bugs/1348/.

Thanks,
Rhys

Re: [Gnuplot-info] 'set termoption enhanced' breaks 'set term x11 persist'

[sfeam <eam...@gm...>]

On Sunday, 09 March 2014 12:07:00 PM Rhys Ulerich wrote:
> Just confirmed that the recreate
> 
> > $gnuplot
> > gnuplot> set term x11 persist
> > gnuplot> set termoption enhanced
> > gnuplot> plot sin(x)
> > gnuplot> exit
> 
> misbehaves on 4.6.5 too.
> 
> - Rhys

Please file a bug report on the SourceForge tracker so
we don't lose track of it.   Patches and commentary are
currently coming in torrents due to discussion about
what should be changed, fixed, or added for version 5.
I'm afraid your note here will get lost in the flood.

	Ethan

Re: [Gnuplot-info] 'set termoption enhanced' breaks 'set term x11 persist'

[Rhys U. <rhy...@gm...>]

Just confirmed that the recreate

> $gnuplot
> gnuplot> set term x11 persist
> gnuplot> set termoption enhanced
> gnuplot> plot sin(x)
> gnuplot> exit

misbehaves on 4.6.5 too.

- Rhys

[Gnuplot-info] 'set termoption enhanced' breaks 'set term x11 persist'

[Rhys U. <rhy...@gm...>]

On 4.6.3 I see

$gnuplot
gnuplot> set term x11 persist
gnuplot> plot sin(x)
gnuplot> exit

leave a persistent window as expected while

$gnuplot
gnuplot> set term x11 persist
gnuplot> set termoption enhanced
gnuplot> plot sin(x)
gnuplot> exit

does not.  Curiously,

$ gnuplot -persist
gnuplot> set termoption enhanced
gnuplot> set title 'Foo_0'
gnuplot> plot sin(x)
gnuplot> exit

works and the title confirms that enhanced mode is working here.

- Rhys

[Gnuplot-info] Appending 'save' command results to a file

[Rhys U. <rhy...@gm...>]

It feels weird that
    save '|cat>>foo'
is required to append save command output to an existing file (on
4.6.3 at least).

- Rhys

Re: [Gnuplot-info] continued lines in Emacs gnuplot-mode

[Dima K. <gn...@di...>]

Ethan Merritt <eam...@gm...> writes:

> What about the files gnuplot-eldoc.el and gnuplot-eldoc.elc that are
> generated from the master documentation file gnuplot.doc?    Are they part
> of gnuplot-mode or are they for something else entirely?

Those aren't a part of gnuplot-mode. The .elc is a byte-compiled version
of the .el.

gnuplot-eldoc.el looks like it is meant to provide completion when
creating gnuplot scripts, but it was never being installed in any
meaningful way, so I've never used it (or heard of it for that matter).
The newer gnuplot-mode tree provides this functionality in a different
way. I'm pretty sure those files could be removed. They were
undiscoverable, and are now handled in a more logical (and obvious)
place.

dima

Re: [Gnuplot-info] continued lines in Emacs gnuplot-mode

[Ethan M. <eam...@gm...>]

What about the files gnuplot-eldoc.el and gnuplot-eldoc.elc that are
generated from the master documentation file gnuplot.doc?    Are they part
of gnuplot-mode or are they for something else entirely?


On Thu, Mar 6, 2014 at 2:21 AM, Elias Assmann <eli...@gm...>wrote:

> Hi Dima,
>
> On 03/05/2014 09:59 PM, Dima Kogan wrote:
> > Hi Elias. The gnuplot emacs interface in the gnuplot distribution is out
> > of date. A very updated mode is here:
>
> Way out of date actually!  I did not really look at the header.
>
> And good catch, I have to say -- I did not say which source I was using.
>
> >   https://github.com/bruceravel/gnuplot-mode
> >
> > You should patch that tree (if it doesn't have your fixes already).
>
> In fact, this already has
>
> (defun gnuplot-send-line-to-gnuplot ()
> …
>         (save-excursion
>            ;; go to start of continued command, or beginning of line
>            ;; if this is not a continuation of a previous line <JJO>
>            (gnuplot-beginning-of-continuation)
> …
>
> For what it's worth, I agree that it would be better to remove the
> outdated gnuplot.el from the gnuplot distribution :-).
>
> Thank you for pointing me to the new version.
>
>         Elias
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>

Re: [Gnuplot-info] continued lines in Emacs gnuplot-mode

[Elias A. <eli...@gm...>]

Hi Dima,

On 03/05/2014 09:59 PM, Dima Kogan wrote:
> Hi Elias. The gnuplot emacs interface in the gnuplot distribution is out
> of date. A very updated mode is here:

Way out of date actually!  I did not really look at the header.

And good catch, I have to say -- I did not say which source I was using.

>   https://github.com/bruceravel/gnuplot-mode
>
> You should patch that tree (if it doesn't have your fixes already).

In fact, this already has

(defun gnuplot-send-line-to-gnuplot ()
…
	(save-excursion
           ;; go to start of continued command, or beginning of line
           ;; if this is not a continuation of a previous line <JJO>
           (gnuplot-beginning-of-continuation)
…

For what it's worth, I agree that it would be better to remove the 
outdated gnuplot.el from the gnuplot distribution :-).

Thank you for pointing me to the new version.

	Elias

Re: [Gnuplot-info] continued lines in Emacs gnuplot-mode

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> On Wednesday, 05 March 2014 12:59:17 PM Dima Kogan wrote:
>
>> Ethan and co: this came up last year, but we didn't do anything about
>> it. Can we either remove the gnuplot emacs mode from the CVS tree (since
>> it's maintained in github already), or make it obvious that the
>> gnuplot.el hosted HERE is a mirror rather than the upstream?
>  
> I would be happy to remove it.
> But I didn't feel comfortable making that decision myself because
> I am not an emacs user and have no feel for who would be
> inconvenienced or otherwise unhappy if it disappears.
>
> Could you write up a short paragraph for the documentation,
> the FAQ, and the README explaining what gnuplot-mode is,
> who might want to use it, and where to find it?

Hi Ethan.

Here's a description that mostly comes from the source:

================================================================

The emacs gnuplot-mode is a major mode for composing gnuplot scripts and
displaying their results using gnuplot. It can be obtained from MELPA or
from a distribution such as Debian or Ubuntu. Otherwise, the source
lives at

 https://github.com/bruceravel/gnuplot-mode

This mode offers several tools to help you compose your scripts,
including font-lock syntax colorization, a syntax table appropriate
to gnuplot, key bindings, pull-down menus, indentation, keyword
completions and variable customization using the Custom package.
Once the script is composed, there are several function for sending
some or all of the script to gnuplot.  The interaction with the
gnuplot process is within a comint buffer.  Plots can optionally be
displayed within Emacs.
================================================================

In non-emacs-speak, it provides facilities to make writing and running
scripts easier. I really do think it should be removed. Not only does
emacs have standardized packaging infrastructure that has this package
in it, distros such as Debian carry it too. It's a bit of a historical
accident that this ever lived in the gnuplot tree, but there's no reason
for it at all anymore. If we have a list somewhere of frontends and
libraries that use gnuplot, we should mention it there.

dima

Re: [Gnuplot-info] continued lines in Emacs gnuplot-mode

[Ethan A M. <eam...@gm...>]

On Wednesday, 05 March 2014 12:59:17 PM Dima Kogan wrote:

> Hi Elias. The gnuplot emacs interface in the gnuplot distribution is out
> of date. A very updated mode is here:
> 
>  https://github.com/bruceravel/gnuplot-mode
> 
> You should patch that tree (if it doesn't have your fixes already).
> 
> Ethan and co: this came up last year, but we didn't do anything about
> it. Can we either remove the gnuplot emacs mode from the CVS tree (since
> it's maintained in github already), or make it obvious that the
> gnuplot.el hosted HERE is a mirror rather than the upstream?
 
> dima

I would be happy to remove it.
But I didn't feel comfortable making that decision myself because
I am not an emacs user and have no feel for who would be
inconvenienced or otherwise unhappy if it disappears.

Could you write up a short paragraph for the documentation,
the FAQ, and the README explaining what gnuplot-mode is,
who might want to use it, and where to find it?

	thanks,

		Ethan


> Elias Assmann <eli...@gm...> writes:
> 
> > Hi,
> >
> > In gnuplot-mode, ‘gnuplot-send-line-to-gnuplot’ (C-c C-l) helpfully 
> > searches forward to the end of a continued line.  However, I thought it 
> > would be even more helpful to also search backward to the beginning of 
> > the logical line.
> >
> > So below, you will find a version of the function that does that.
> >
> > HTH,
> >
> > 	Elias
> >
> >
> > PS: My knowledge of Emacs Lisp is very incomplete …
> >
> > PPS: gnuplot-mode redefines C-m to newline-and-indent.  This makes it 
> > awkward to get a newline without any indention.  In my experience, most 
> > Emacs modes use C-j for “smart newline” (whatever that may mean in the 
> > mode's context) but leave C-m to mean plain newline.
>