Why do we need a number of different terminal modes in Emacs?

Why do we need a number of different terminal modes in Emacs?

[Andrey Lisin]

Hi everyone,

could anyone explain me why do we need several of terminal
implementations inside Emacs? Shell, eshell, term, ansi-term... And as
far as I noticed they all suck one way or another. For example, shell
cannot complete commands when you ssh to remote server inside it. Eshell
tragically cannot do a very simple thing - source a bash script. Really,
try to run `. some_script.sh' or `source some_script.sh' inside eshell.

So, am I right and we need them all just because one solves restrictions
of the others and others do the same thing for the one? Why then not
just to write some standard terminal implementation, that will just
works? Does it have something with cross-platform nature of Emacs? Or,
maybe I'm doing something wrong and all this stuff makes sense? Thank
you.

Re: Why do we need a number of different terminal modes in Emacs?

[Robert Thorpe]

Andrey Lisin <andrey.lisin@gmail.com> writes:

> Hi everyone,
>
> could anyone explain me why do we need several of terminal
> implementations inside Emacs? Shell, eshell, term, ansi-term... And as
> far as I noticed they all suck one way or another. For example, shell
> cannot complete commands when you ssh to remote server inside it. Eshell
> tragically cannot do a very simple thing - source a bash script. Really,
> try to run `. some_script.sh' or `source some_script.sh' inside eshell.
>
> So, am I right and we need them all just because one solves restrictions
> of the others and others do the same thing for the one? Why then not
> just to write some standard terminal implementation, that will just
> works? Does it have something with cross-platform nature of Emacs? Or,
> maybe I'm doing something wrong and all this stuff makes sense? Thank
> you.

I'll explain the trickiness.  Shell-mode works in an Emacs-like manner.
It hooks to an external shell, such as bash, ksh or tcsh.  It transfers
*lines* to the shell.  It has to work this way, since the line is edited by
Emacs editing commands.  Emacs editing commands work exactly as they do
elsewhere in Emacs.  For example, if you do C-a in tcsh or sh it will
bring you to the beginning of the line, that's not a feature of those
shells.  You can define keymaps for any key you like.

The shell-mode system can only work for programs with line-orientated
input.  A program that responds to keys one at a time can't be handled
this way.  Shell modes doesn't even try to do this, or to deal with
programs that have text-based GUIs, like "top" or curses programs.  Type
"top" in shell and see what happens.  Notice you have to type "q RET" to
exit, not just "q".

So, we have the terminal modes: ansi-term and term.  These emulate
*terminals* imperfectly, and a shell runs under that terminal.  These
have two modes, line mode and character mode.  In line-mode they behave
like shell mode as I described above.  In character mode they relay
characters one-at-a-time to the inferior program.  You switch between
the two modes with C-c C-j and C-c C-k.  Emacs only catches a few keys,
C-x, C-c, C-num and a few other without passing them through (see C-h m
in term-mode).  You can run programs with text-based GUIs like "top" and
"emacs -nw" in terms.

For example.  Go into term mode using bash.  Type some stuff in and
press M-b & M-f to move across words.  This works in either character
mode (C-c C-k) or line mode (C-c C-k).  It works in line mode because
those are Emacs keybindings and it works in character mode because
they're bash keybindings.  Now, run another shell like dash.  Try M-b &
M-f there.  They will work in line mode but fail in character mode.

There is little difference between term and ansi-term.  In the past only
ansi-term had colours, now both do.  The prefix key is C-c in term and
C-x in ansi-term.

Eshell is a completely different thing.  It's a shell written in Emacs
Lisp.  The idea of it is that you can write lisp at the command prompt
as well as calling shell programs.  For example you can write (+ 2 3) at
the eshell prompt and it will return 5.  Eshell can't source bash scripts
because bash is nowhere in sight here.  Like shell-mode it doesn't
emulate a terminal or have a character mode, so you can't use it with
the programs that need that.

For your use I think term in line-mode would be best, switching to
character mode when necessary.

BR,
Robert Thorpe

Re: Why do we need a number of different terminal modes in Emacs?

[Andrey Lisin]

Hi Robert,

I am very grateful to you for the detailed answer. I can say now I
understand this mess with terminals in Emacs! Thanks again!

Re: Why do we need a number of different terminal modes in Emacs?

[Marcin Borkowski]

On 2015-02-01, at 08:09, Andrey Lisin <andrey.lisin@gmail.com> wrote:

> [...] Eshell
> tragically cannot do a very simple thing - source a bash script. Really,
> try to run `. some_script.sh' or `source some_script.sh' inside eshell.

You know, it's even worse than that: can you imagine that you can't
extend Emacs in Java?  Try

(defun myCoolAbstractPublicStaticVoidGenericVirtualUnicodeCharacterFactory ()
  ...)

and put some Java code in place of "...".  It won't work!  How tragic!

(SCNR - please, don't get offended;-).  In fact, your question is imho
not an unreasonable one.  And I haven't yet read any answers of
others...)

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Karl Voit]

* Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
>
> I'll explain the trickiness.  Shell-mode works in an Emacs-like manner.
> It hooks to an external shell, such as bash, ksh or tcsh.  It transfers
> *lines* to the shell.  It has to work this way, since the line is edited by
> Emacs editing commands.
[...]

Thank you very much for your detailed explanation!

However, this confirms my habit of using a Terminal emulator, with
GNU/screen[1], together with a great set-up of zsh[2].

Unfortunately, my GNU/Emacs tends to be very unstable[3] so that I
have to kill and re-start it several times a day. I handle this by
having a very tight auto-save-interval. Losing all of my open shell
sessions would be a disaster.

Sure, I have to copy&paste a lot between zsh and Emacs. However,
Org-mode/babel helps for very simple things as well.

Additionally, I need to sync Org-mode files, detach GNU/screen
sessions, log off the computer, put it into sleep mode, switch
computer, re-start GNU/Emacs session with synced Org-mode files, and
return to the other computer later on. Therefore, my GNU/screen
sessions run for much longer than my GNU/Emacs sessions.

I could not find good enough reasons to move my shell into GNU/Emacs
- even though I do basically everything inside Org-mode.


Quite recently, I stumbled over org-screen/ob-screen but it didn't
gave me enough advantages.


[1] Found no time or urgent reason to switch to tmux yet

[2] http://grml.org/zsh/

[3] Different story, hard to fix by myself and hard to imitate for
    peers. I did not find an Emacs guru willing to spend time with
    me infront of my keyboard.
-- 
All in all, one of the most disturbing things today is the definitive
fact that the NSA, GCHQ, and many more government organizations are
massively terrorizing the freedom of us and the next generations.
                                                  http://Karl-Voit.at

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Robert Thorpe]

Karl Voit <devnull@Karl-Voit.at> writes:
...
> However, this confirms my habit of using a Terminal emulator, with
> GNU/screen[1], together with a great set-up of zsh[2].

You can use GNU Screen and Zsh and connect to them using M-x term.  That
puts them within Emacs, but Screen should make things safe from Emac's
crashes.

As I was saying in another thread, there's a bit about doing it with
Screen here http://www.emacswiki.org/emacs/GnuScreen , there are couple
of gotchas and things you have to setup in Screen's rc file.

> Unfortunately, my GNU/Emacs tends to be very unstable[3] so that I
> have to kill and re-start it several times a day. I handle this by
> having a very tight auto-save-interval. Losing all of my open shell
> sessions would be a disaster.

Have you bisected your init file?

Even for an intermittant bug that can help a lot.  Let's say you cut out
half of your init file and work with Emacs for a few hours.  If the problem
doesn't happen you can be pretty sure it's in the cut out bit.  If it
does happen you can be sure it's in the bit left.  If you're getting
crashes about four times a day then you can make a bisect decision every
couple of hours.  So you should be able to identify the 1/8th or 1/16th
of you init file that's to blame :).

BR,
Rob

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Karl Voit]

* Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
> Karl Voit <devnull@Karl-Voit.at> writes:
> ...
>> However, this confirms my habit of using a Terminal emulator, with
>> GNU/screen[1], together with a great set-up of zsh[2].
>
> You can use GNU Screen and Zsh and connect to them using M-x term.  That
> puts them within Emacs, but Screen should make things safe from Emac's
> crashes.

And what advantages would I get?

>> Unfortunately, my GNU/Emacs tends to be very unstable[3] so that I
>> have to kill and re-start it several times a day. I handle this by
>> having a very tight auto-save-interval. Losing all of my open shell
>> sessions would be a disaster.
>
> Have you bisected your init file?

No.

Most issues only appear in my "GNU Emacs 24.3.50.1
(x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of 2014-01-01 on gkar,
modified by Debian" and not in my GNU Emacs I use on Windows.

Therefore I have the strong feeling that my Emacs backport for
Debian/Wheezy is the cause for some issues.

-- 
All in all, one of the most disturbing things today is the definitive
fact that the NSA, GCHQ, and many more government organizations are
massively terrorizing the freedom of us and the next generations.
                                                  http://Karl-Voit.at

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Robert Thorpe]

Karl Voit <devnull@Karl-Voit.at> writes:

> * Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
>> Karl Voit <devnull@Karl-Voit.at> writes:
>> ...
>>> However, this confirms my habit of using a Terminal emulator, with
>>> GNU/screen[1], together with a great set-up of zsh[2].
>>
>> You can use GNU Screen and Zsh and connect to them using M-x term.  That
>> puts them within Emacs, but Screen should make things safe from Emac's
>> crashes.
>
> And what advantages would I get?

You get to work inside Emacs and Screen should stop your terminals from
getting hosed when Emacs crashes.

>>> Unfortunately, my GNU/Emacs tends to be very unstable[3] so that I
>>> have to kill and re-start it several times a day. I handle this by
>>> having a very tight auto-save-interval. Losing all of my open shell
>>> sessions would be a disaster.
>>
>> Have you bisected your init file?
>
> No.

I have an MS Windows specific part of my init file and an Ubuntu specific
part.  If you do the same then it could be a bug your Debian specific
part.  It could also be a bug in Debian's site-start code, a lot of that
distro site-start code is old and crufty.

> Most issues only appear in my "GNU Emacs 24.3.50.1
> (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of 2014-01-01 on gkar,
> modified by Debian" and not in my GNU Emacs I use on Windows.
>
> Therefore I have the strong feeling that my Emacs backport for
> Debian/Wheezy is the cause for some issues.

What's the 50 in 24.3.50.1?  Is it a number used by Debian to do their
versioning?  Or does it mean you're using an unreleased version of
Emacs?  If it's the latter then that's probably the problem.

If not I'd try a different Emacs build.  I'm using an old version of
XUbuntu with an Emacs from some PPA and it works fine.

BR,
Robert Thorpe

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Emanuel Berg]

Karl Voit <devnull@Karl-Voit.at> writes:

>> You can use GNU Screen and Zsh and connect to them
>> using M-x term. That puts them within Emacs, but
>> Screen should make things safe from Emacs' crashes.
>
> And what advantages would I get?

Complete integration of the material
inputted/outputted, the same editing keys, the same
configuration/documentation interface, ...

-- 
underground experts united

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Karl Voit]

Hi!

* Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
> Karl Voit <devnull@Karl-Voit.at> writes:
>
>> * Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
>>> Karl Voit <devnull@Karl-Voit.at> writes:
>>>
>>> You can use GNU Screen and Zsh and connect to them using M-x term.  That
>>> puts them within Emacs, but Screen should make things safe from Emac's
>>> crashes.
>>
>> And what advantages would I get?
>
> You get to work inside Emacs and Screen should stop your terminals from
> getting hosed when Emacs crashes.

Sorry, I meant what advantages do I get compared to a separate
Terminal emulation running my GNU screen sessions?

I don't see much difference between Alt-TAB + XOrg-copy&paste and
C-x b + Emacs-copy&paste

>>>> Unfortunately, my GNU/Emacs tends to be very unstable[3] so that I
>>>> have to kill and re-start it several times a day. I handle this by
>>>> having a very tight auto-save-interval. Losing all of my open shell
>>>> sessions would be a disaster.
>>>
>>> Have you bisected your init file?
>>
>> No.
>
> I have an MS Windows specific part of my init file and an Ubuntu specific
> part.  If you do the same then it could be a bug your Debian specific
> part.  It could also be a bug in Debian's site-start code, a lot of that
> distro site-start code is old and crufty.

OK.

>> Most issues only appear in my "GNU Emacs 24.3.50.1
>> (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of 2014-01-01 on gkar,
>> modified by Debian" and not in my GNU Emacs I use on Windows.
>>
>> Therefore I have the strong feeling that my Emacs backport for
>> Debian/Wheezy is the cause for some issues.
>
> What's the 50 in 24.3.50.1?  Is it a number used by Debian to do their
> versioning?  

No idea.

> Or does it mean you're using an unreleased version of
> Emacs?  If it's the latter then that's probably the problem.

The package is called emacs-snapshot. Debian GNU/Linux Wheezy was
providing no Emacs 24 to me. Therefore I installed the snapshot
package.

> If not I'd try a different Emacs build.  I'm using an old version of
> XUbuntu with an Emacs from some PPA and it works fine.

Which Debian Wheezy packages from which source do you recommend?


(I will not compile anything on my own any more since I wont
handle any compile errors or missing dependencies.)

-- 
All in all, one of the most disturbing things today is the definitive
fact that the NSA, GCHQ, and many more government organizations are
massively terrorizing the freedom of us and the next generations.
                                                  http://Karl-Voit.at

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Bob Proulx]

Karl Voit wrote:
> Robert Thorpe wrote:
> > Or does it mean you're using an unreleased version of
> > Emacs?  If it's the latter then that's probably the problem.
> 
> The package is called emacs-snapshot. Debian GNU/Linux Wheezy was
> providing no Emacs 24 to me. Therefore I installed the snapshot
> package.

There is no emacs-snapshot in Wheezy.  Where did you pull the
emacs-snapshot package from?

When I heard you report that emacs crashed often for you I shrugged it
off thinking you were probably using it on a foreign operating system.
But then I was really surprised that you were using Wheezy.  I use
emacs on Debian Wheezy and Sid and it is rock solid for me.  It has
been literally years since I remember having seen an emacs crash.

> > If not I'd try a different Emacs build.  I'm using an old version of
> > XUbuntu with an Emacs from some PPA and it works fine.
> 
> Which Debian Wheezy packages from which source do you recommend?
> 
> (I will not compile anything on my own any more since I wont
> handle any compile errors or missing dependencies.)

Debian Wheezy 7 shipped May 4th, 2013 with emacs v23.  The upcoming
Jessie 8 will release with emacs v24.  For Wheezy 7 if you wish to use
emacs 24 the best recommendation is probably to use a backported
version backported from Jessie to Wheezy.

  http://backports.debian.org/

Basically add this to your sources.list file.

  deb http://http.debian.net/debian wheezy-backports main contrib non-free

Then apply the backports target (-t wheezy-backports) when installing.

  apt-get -t wheezy-backports install emacs24 emacs24-common-non-dfsg

However do note that installing a backport for something as large as
emacs will pull in a lot of dependent libraries.  That is fine.
Upgrades to Jessie 8 will occur normally when upgrading.  But when
installing other applications the dependency chain may require
including backports in the target list for other things, especially
anything graphical, from then forward.  Eventually when you upgrade to
Jessie as the new Stable all of that is resolved and goes away.

Personally I use emacs v23 on Wheezy 7 and have no complaints.  In
fact every upgrade for me causes me to need to spend a bunch of time
and resources to understand the new changes and to make adjustments so
that it continues to be usable for me.  If I had the option to have a
rock solid version of emacs over one that crashed regularly I would
definitely choose the stable one!  At some point everyone must ask
themselves how much time can the spend chasing shadows?  I recommend
using the version with the Debian Stable release and then upgrading
when the stable release upgrades.  Of course the choice is yours.

Bob

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Emanuel Berg]

Karl Voit <devnull@Karl-Voit.at> writes:

> Sorry, I meant what advantages do I get compared to
> a separate Terminal emulation running my GNU screen
> sessions?
>
> I don't see much difference between Alt-TAB +
> XOrg-copy&paste and C-x b + Emacs-copy&paste

It is not only a matter of copy and paste back and
forth! If that is your only concern the whole system
is integrated as it is.

No, if you have any data in an Emacs buffer, you can
immediately put all of Emacs to work on that data,
just as you can put all of Emacs to (re)produce it.
And this can be automatized big with no glue in
between.

Now that sounded really advanced but it can be really
down to Earth things. You will experience the benefits
of an integrated interface with common input methods
and documentation/configuration very soon if you
didn't already.

-- 
underground experts united

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Robert Thorpe]

Karl Voit <devnull@Karl-Voit.at> 
> * Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
>> Karl Voit <devnull@Karl-Voit.at> writes:
>>
...
>>> And what advantages would I get?
>>
>> You get to work inside Emacs and Screen should stop your terminals from
>> getting hosed when Emacs crashes.
>
> Sorry, I meant what advantages do I get compared to a separate
> Terminal emulation running my GNU screen sessions?
>
> I don't see much difference between Alt-TAB + XOrg-copy&paste and
> C-x b + Emacs-copy&paste

It depends on how much use you make of Emacs specific features.  Since
bash has the same cursor movement commands as Emacs those aren't so
important.  In terminal line-mode or shell mode you can use M-/
(dabbrev-expand).  So, if you're writing a shell script or I have a file
open that contains shell commands you don't need to copy & paste so
much, you can write a few character of the command and complete it with
M-/.  If you don't use these facilities though then it's best to xterm
because it does better terminal emulation.

> The package is called emacs-snapshot. Debian GNU/Linux Wheezy was
> providing no Emacs 24 to me. Therefore I installed the snapshot
> package.

Snapshots are generally not very reliable.

> Which Debian Wheezy packages from which source do you recommend?

I don't know about Debian.  Others have posted about that.

I understand that Debian & Ubuntu are similar though.  On Ubuntu there
are things called "PPAs", "personal package archives".  People can host
them and put up things they've built.  Someone has put up a backport of
Emacs 23.4 which uses the libraries I already have (which avoids the
problem of regular backports which is the huge number of libraries they
drag along).  Perhaps something similar is available under Debian.

BR,
Robert Thorpe

Re: zsh outside of Emacs

[Tory S. Anderson]

Emanuel puts it well; that sort of integrated interface and the ability to put emacs tools to use on my bash output has served me many, many times. It's hard for me to go back to a "dumb terminal" (to use the term ironically) now...

Emanuel Berg <embe8573@student.uu.se> writes:

> Karl Voit <devnull@Karl-Voit.at> writes:
>
>> Sorry, I meant what advantages do I get compared to
>> a separate Terminal emulation running my GNU screen
>> sessions?
>>
>> I don't see much difference between Alt-TAB +
>> XOrg-copy&paste and C-x b + Emacs-copy&paste
>
> It is not only a matter of copy and paste back and
> forth! If that is your only concern the whole system
> is integrated as it is.
>
> No, if you have any data in an Emacs buffer, you can
> immediately put all of Emacs to work on that data,
> just as you can put all of Emacs to (re)produce it.
> And this can be automatized big with no glue in
> between.
>
> Now that sounded really advanced but it can be really
> down to Earth things. You will experience the benefits
> of an integrated interface with common input methods
> and documentation/configuration very soon if you
> didn't already.

Re: zsh outside of Emacs (was: Why do we need a number of different terminal modes in Emacs?)

[Karl Voit]

* Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
> Karl Voit <devnull@Karl-Voit.at> 
>> * Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
>>> Karl Voit <devnull@Karl-Voit.at> writes:
>>>
>> I don't see much difference between Alt-TAB + XOrg-copy&paste and
>> C-x b + Emacs-copy&paste
>
> It depends on how much use you make of Emacs specific features.  Since
> bash 

I am using zsh. However, my zsh has default Emacs bindings as well.

> has the same cursor movement commands as Emacs those aren't so
> important.  In terminal line-mode or shell mode you can use M-/
> (dabbrev-expand).  So, if you're writing a shell script or I have a file
> open that contains shell commands you don't need to copy & paste so
> much, you can write a few character of the command and complete it with
> M-/.  If you don't use these facilities though then it's best to xterm
> because it does better terminal emulation.

I see.

OK, this confirms my point of view. Thank you.

>> The package is called emacs-snapshot. Debian GNU/Linux Wheezy was
>> providing no Emacs 24 to me. Therefore I installed the snapshot
>> package.
>
> Snapshots are generally not very reliable.

Back then it was either this snapshot package or compile myself (no
way!) or stay on Emacs 23 (no way). My package is still current I
guess. Have to look for a different source of Debian packages.

>> Which Debian Wheezy packages from which source do you recommend?
>
> I don't know about Debian.  Others have posted about that.
>
> I understand that Debian & Ubuntu are similar though.  On Ubuntu there
> are things called "PPAs", "personal package archives".  People can host
> them and put up things they've built.  Someone has put up a backport of
> Emacs 23.4 which uses the libraries I already have (which avoids the
> problem of regular backports which is the huge number of libraries they
> drag along).  Perhaps something similar is available under Debian.

Ubuntus PPAs imitate the behavior of Debian (the original). I am not
sure about the compatibility of an Ubuntu-PPA and Debian stable but
the underlying methods are the same.

-- 
All in all, one of the most disturbing things today is the definitive
fact that the NSA, GCHQ, and many more government organizations are
massively terrorizing the freedom of us and the next generations.
                                                  http://Karl-Voit.at

gnuplot (was: Re: zsh outside of Emacs)

[Emanuel Berg]

(on topic: gnuplot - last paragraph!)

torys.anderson@gmail.com (Tory S. Anderson) writes:

>> It is not only a matter of copy and paste back and
>> forth! If that is your only concern the whole
>> system is integrated as it is. No, if you have any
>> data in an Emacs buffer, you can immediately put
>> all of Emacs to work on that data, just as you can
>> put all of Emacs to (re)produce it. And this can be
>> automatized big with no glue in between. Now that
>> sounded really advanced but it can be really down
>> to Earth things. You will experience the benefits
>> of an integrated interface with common input
>> methods and documentation/configuration very soon
>> if you didn't already.
>
> Emanuel puts it well; that sort of integrated
> interface and the ability to put emacs tools to use
> on my bash output has served me many, many times.

Thanks for the compliment. You know what they say: a
great Useneter always have one last great post left in
his tank...

Yes, integration is one of the top three or four
benefits of Emacs. To me, it is the most enjoyable
with mail/Usenet (Gnus), then the web (Emacs-w3m), and
only then manpages and the shell. But it depends what
you do, of course, where you are the most benefited.

> It's hard for me to go back to a "dumb terminal" (to
> use the term ironically) now...

Indeed, you never want to take a step back from what
you have achieved. And that can be a problem whenever
you cannot decide what to use... (a "problem" as in
frustration)

Uncanny, by the way, your mention of a "dumb
terminal"! Just before I read your post I did a
gnuplot .gpi file and added a 'set terminal dumb' line
for fast ASCII-only checks. Speaking of gnuplot, I had
to to get gnuplot-mode from MELPA - that was super
easy, but why isn't such a basic mode included in
vanilla Emacs, to offer font lock, indentation, and
invocation? For the few of you who don't know gnuplot
this can serve as an introduction [1] - the Makefile
got a bit complicated, but it isn't anything a
computer literate person cannot decipher in zero time.
Gnuplot is great and can be used not just for
techno-techno-science but for writing, journalism, and
plain cool facts just as well. It should definitely be
associated with Emacs from the holster in all ways
possible, is what I think.

[1] http://user.it.uu.se/~embe8573/hs-linux/docs/report/pics/plot

-- 
underground experts united

Re: gnuplot (was: Re: zsh outside of Emacs)

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> for fast ASCII-only checks. Speaking of gnuplot, I had
> to to get gnuplot-mode from MELPA - that was super
> easy, but why isn't such a basic mode included in
> vanilla Emacs, to offer font lock, indentation, and
> invocation? For the few of you who don't know gnuplot

Perhaps because the authors haven't copyright assigned it to the FSF?
The name "gnuplot" is a coincidence, the program and it's authors have
nothing to do with the GNU project.  That's not to say it's not a great
program, it is.

BR,
Robert Thorpe

Re: gnuplot (was: Re: zsh outside of Emacs)

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

>> for fast ASCII-only checks. Speaking of gnuplot, I
>> had to to get gnuplot-mode from MELPA - that was
>> super easy, but why isn't such a basic mode
>> included in vanilla Emacs, to offer font lock,
>> indentation, and invocation? For the few of you who
>> don't know gnuplot
>
> Perhaps because the authors haven't copyright
> assigned it to the FSF? The name "gnuplot" is a
> coincidence, the program and it's authors have
> nothing to do with the GNU project. That's not to
> say it's not a great program, it is.

Do you mean gnuplot-mode has a missing/conflicting
license, or gnuplot has? With gnuplot that should be
OK as there are built-in modes for God knows what
technologies that most likely have licenses all over
the place, including none at all.

-- 
underground experts united

Re: gnuplot (was: Re: zsh outside of Emacs)

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:
...
>
> Do you mean gnuplot-mode has a missing/conflicting
> license, or gnuplot has? With gnuplot that should be
> OK as there are built-in modes for God knows what
> technologies that most likely have licenses all over
> the place, including none at all.

I don't know why it's not included.

Possible reasons:
* The Emacs developers don't think it's important enough.
* It has a non GPL license.
* The Emacs developers can't get copyright assignment for it.

The FSF generally require that Emacs coders assign copyright to them.
Unless it's a small change it's not considered good enough to just use
the GPLv3 license.  As far as I understand it, there are two reasons for
that.  Firstly, it enables them to easily re-license the code.  That
could happen if a legal flaw is found in a license, for example GPLv3
was created to rectify problems with GPLv2.  The other advantage is that
it prevents programmers from being able to relicense their contributions
and request that they're removed.

What sometimes happens is that an elisp package is initially unpopular.
But, the author gathers contributions from many people.  Then the
package becomes popular and people want it in the core or ELPA.  But by
that time the author can't find all the people to contact to ask for
copyright paperwork, or there are so many of them that it isn't
practical.

You could try asking for it to be included in the core it may be
possible.

BR,
Robert Thorpe

Re: gnuplot (was: Re: zsh outside of Emacs)

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> You could try asking for it to be included in the
> core it may be possible.

If there are complications, I don't have a problem
with the current state. It is no big deal. If a person
is intelligent enough to find both Emacs and gnuplot
then I have confidence [s]he will be able to use MELPA
to get the mode as well.

-- 
underground experts united