Does anyone really use emacs in terminal?

[Steven Degutis]

What's the use-case for having the terminal be able to act as an editor?

For me it's rather the other way around, I use the terminal within my
editor (eshell).

Seems like there's no real point in supporting terminal-mode in a text
editor these days.

-Steven

[Chad Brown]

On Saturday, May 4, 2013 8:06:58 PM UTC-7, Steven Degutis wrote:
> What's the use-case for having the terminal be able to act as an editor?

Remote editing on systems that have SSH but not X11. Android and iOS tablets and phones are pretty common.

It's also pretty nice with something like screen or tmux.

[Le Wang]

The cool kids do it.

You can find many screencasts of people doing everything in terminal and proselytising the simplicity and lack of distractions of such a work flow.  They don't mention the lack of features, and the pitfalls.

As a result a lot of the newbie questions on stackoverflow and here are "Why dozn't M-return work with me Emacs?" and "How comez when I can't cut'n'paste from Emacs?".

This is frustratingly detrimental to Emacs adoption because the new user's initial experience with Emacs is "fixing" it.

On Sun, May 5, 2013 at 11:06 AM, Steven Degutis <sbde...@gmail.com> wrote:

What's the use-case for having the terminal be able to act as an editor?

For me it's rather the other way around, I use the terminal within my
editor (eshell).

Seems like there's no real point in supporting terminal-mode in a text
editor these days.

-Steven

--
Le

[XeCycle]

Steven Degutis <sbde...@gmail.com> writes:

> What's the use-case for having the terminal be able to act as an editor?
>
> For me it's rather the other way around, I use the terminal within my
> editor (eshell).
>
> Seems like there's no real point in supporting terminal-mode in a text
> editor these days.

There apparently are such use cases.

You may also argue on MSDOS support in Emacs; but of course, even
if we decided to drop this support, someone can still distribute
his fork of Emacs with MSDOS support.

The same with terminal support.

Indeed GUI isn't anything different. We can also decide to
distribute Emacs with terminal support only, and let someone else
to distribute their GUI fork.

Therefore such argues are pointless. As long as someone are
maintaining the relevant code, inclusion of the support does more
good than bad.

--
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

[Steven Degutis]

I'm so tired of how Emacs so desperately clings onto the 80s and 90s.

So many of its defaults are idiotic, so many legacy features it tries
to support are just terrible and useless.

I often wish there was a modern emacs clone that dropped all these
legacy features.

Who ever uses a toolbar?
Why don't the scrollbars work like normal?
Why is the undo feature so ridiculous, instead of something more sane
like undo-tree?
Why isn't ido-mode enabled by default, and why doesn't it work on more
completable prompts without a third party plugin?

On Sat, May 4, 2013 at 10:58 PM, Le Wang <l26...@gmail.com> wrote:
> The cool kids do it.
>
> You can find many screencasts of people doing everything in terminal and
> proselytising the simplicity and lack of distractions of such a work flow.
> They don't mention the lack of features, and the pitfalls.
>
> As a result a lot of the newbie questions on stackoverflow and here are "Why
> dozn't M-return work with me Emacs?" and "How comez when I can't cut'n'paste
> from Emacs?".
>
> This is frustratingly detrimental to Emacs adoption because the new user's
> initial experience with Emacs is "fixing" it.
>
>
> On Sun, May 5, 2013 at 11:06 AM, Steven Degutis <sbde...@gmail.com> wrote:
>>

>> What's the use-case for having the terminal be able to act as an editor?
>>
>> For me it's rather the other way around, I use the terminal within my
>> editor (eshell).
>>
>> Seems like there's no real point in supporting terminal-mode in a text
>> editor these days.
>>

>> -Steven
>>
>
>
>
> --
> Le

[Bob Proulx]

Steven Degutis wrote:
> What's the use-case for having the terminal be able to act as an editor?

> ...

> Seems like there's no real point in supporting terminal-mode in a text
> editor these days.

I use emacs in a terminal all of the time every day. How else are you
going to edit files while logged into a remote server?

If emacs didn't support the text terminal anymore, something that it
has done since the beginning, then it could hardly be called emacs
anymore could it? It would then be something different. Like
gtk-emacs or something. Which is fine. But if emacs weren't
available to edit files would you expect we would use vi? Horrors!

Bob

[Steven Degutis]

Any time I find myself editing files on a remote server, it's because
I stupidly didn't prepare for the task properly and have to fix
something "live". This is never a planned situation, and one I should
really be avoiding rather than catering to. And in those rare times
that I still find myself editing remote files, the server usually only
has vim anyway, which gets the job done. This isn't a legitimate
reason to have terminal support in a text editor that you use on a
daily basis on your local GUI-enabled desktop.

[Bob Proulx]

Steven Degutis wrote:
> I'm so tired of how Emacs so desperately clings onto the 80s and 90s.

I am so tired of how people take current working tools and modify them
to be something completely different that breaks it for everyone who
was using it. GNOME 3 is a good recent example but there are others
before it.

If you want to take emacs, or any other tool, and fork it off and go
into a different direction that is great! I fully support you doing
that. Emacs has been forked many times already. That is one of the
awesome things about free(dom) software. It gives you the ability to
modify and customize it. If you think emacs is backwards then write
it your way reversed. Call it "scame" because it wouldn't be emacs.

But don't break the existing emacs users to build that new tool. Just
build that new tool. Don't make your gain a loss for others.

"I love you. You are perfect. Now change." I *hate* that!

> So many of its defaults are idiotic, so many legacy features it tries
> to support are just terrible and useless.

Then fork it and do your own thing! But please don't break it for me.

> I often wish there was a modern emacs clone that dropped all these
> legacy features.

Do it! The source is there for you. Or start clean with an empty
directory. There are no limits.

Bob

[Pascal J. Bourguignon]

Of course, every day!

Steven Degutis <sbde...@gmail.com> writes:

> What's the use-case for having the terminal be able to act as an editor?

That's rather the other way you should ask: what's the use case of using
a bitmap _graphic_ screen to edit _text_?

That would be a WYSIWYG word processor, I wouldn't say, but we're far
from it with emacs.

> For me it's rather the other way around, I use the terminal within my
> editor (eshell).
>

> Seems like there's no real point in supporting terminal-mode in a text
> editor these days.

There's a lot of point, on the contrary: there are a lot of emacing
done thru the internet, and since we don't have yet gigabit fiber
everywhere, and even if we had it, we may not have guaranteed bandwidth
to all those remote servers on which we have to edit configuration
files, or debug server programs, it is much easier to work with a
terminal thru ssh, than with X11 thru ssh (or even worse, thru vnc).


There are also users with special needs that are not fulfilled by GUI,
but who can work much better with a TUI, ie. with a terminal (eg. blind
people).


Now, of course, when I use emacs locally, I prefer to use it with X11
(but notice, without any decoration (I use ratpoison) or any other GUI
element (I compile it with no X toolkit, and I use it with:
(scroll-bar-mode -1)
(menu-bar-mode -1)
(tool-bar-mode -1)
so if you compared a screenshot of emacs with X11 and emacs on a
terminal (with 256 colors), you wouldn't notice any difference).

Only from time to time, when I visualize a PDF or a PNG, would it make a
difference (but then, on a terminal we could also switch to some bitmap
mode, either with a frame buffer on the console, or switching to the
Tek-4041 mode).


Even when connecting from my iPad (with iSSH), it's easier to use emacs
thru ssh in the terminal, than on X11 (which iSSH provides).

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Jai Dayal]

I do. I use it mostly over ssh on supercomputers.. no need to forward X11 sessions and all that junk. I would say I never use emacs without the terminal.

On Sat, May 4, 2013 at 11:58 PM, Le Wang <l26...@gmail.com> wrote:

The cool kids do it.

You can find many screencasts of people doing everything in terminal and proselytising the simplicity and lack of distractions of such a work flow.  They don't mention the lack of features, and the pitfalls.

As a result a lot of the newbie questions on stackoverflow and here are "Why dozn't M-return work with me Emacs?" and "How comez when I can't cut'n'paste from Emacs?".

This is frustratingly detrimental to Emacs adoption because the new user's initial experience with Emacs is "fixing" it.

On Sun, May 5, 2013 at 11:06 AM, Steven Degutis <sbde...@gmail.com> wrote:

What's the use-case for having the terminal be able to act as an editor?

For me it's rather the other way around, I use the terminal within my
editor (eshell).

Seems like there's no real point in supporting terminal-mode in a text
editor these days.

-Steven

--
Le

[Steven Degutis]

I've wanted to write a text editor, but I don't know how to do syntax
highlighting.

Also, your response reminds me so much of the Workflow xkcd comic.
http://xkcd.com/1172/

[Jai Dayal]

The problem is that you naively assume you can compile things on your desktop that you can your remote server. For me, that's almost never the case, as no desktop or laptop has the hardware that a supercomputer has.

On Sun, May 5, 2013 at 12:17 AM, Steven Degutis <sbde...@gmail.com> wrote:

Any time I find myself editing files on a remote server, it's because
I stupidly didn't prepare for the task properly and have to fix
something "live". This is never a planned situation, and one I should
really be avoiding rather than catering to. And in those rare times
that I still find myself editing remote files, the server usually only
has vim anyway, which gets the job done. This isn't a legitimate
reason to have terminal support in a text editor that you use on a
daily basis on your local GUI-enabled desktop.

On Sat, May 4, 2013 at 11:13 PM, Bob Proulx <b...@proulx.com> wrote:
> Steven Degutis wrote:

>> What's the use-case for having the terminal be able to act as an editor?

>> ...

>> Seems like there's no real point in supporting terminal-mode in a text
>> editor these days.
>

[Steven Degutis]

That's rather the other way you should ask: what's the use case of using a bitmap _graphic_ screen to edit _text_?

Because then my syntax highlighting and color theme has access to some several million colors, not just 256. This, plus viewing it on a retina display, and suddenly the text I stare at all day looks quite beautiful.

[Steven Degutis]

(Oops, redoing that in plain-text mode.)

-Steven

[Pascal J. Bourguignon]

Le Wang <l26...@gmail.com> writes:

> The cool kids do it.
>
> You can find many screencasts of people doing everything in terminal
> and proselytising the simplicity and lack of distractions of such a
> work flow.  They don't mention the lack of features, and the
> pitfalls.
>
> As a result a lot of the newbie questions on stackoverflow and here
> are "Why dozn't M-return work with me Emacs?" and "How comez when I
> can't cut'n'paste from Emacs?".
>
> This is frustratingly detrimental to Emacs adoption because the new
> user's initial experience with Emacs is "fixing" it.

This has nothing to do with emacs, but all to do with lack of knowledge
of said newbies about how terminals and computers work. Direct them to
the corresponding tutorials.

Or direct them to emacs in GUI (X11, Cocoa, MS-Windows).



Otherwise I wouldn't mind if somebody worked on the terminal protocol,
notably on the keyboard part. (ECMA-048 is rich enough, for terminal
output).

I heard there are some extensions implemented in xterm to forward the
status of more modifiers than just control. Some standardization and
wide adoption amongst terminal emulators at least (are physical
terminals still produced?) should do the trick.

[Steven Degutis]

But look at the bigger picture. There's no need to "emulate terminals"
anymore. The vast majority of computers aren't terminals and don't
have anything to do with real terminals. We're stuck in a circular
backwards-compatibility loop: we need terminal emulators because our
programs rely on them (less, cat, ssh, etc), and we write programs to
work on terminal emulators because that's all we have to run them on.

[Pascal J. Bourguignon]

Steven Degutis <sbde...@gmail.com> writes:

> I'm so tired of how Emacs so desperately clings onto the 80s and 90s.
>

> So many of its defaults are idiotic, so many legacy features it tries
> to support are just terrible and useless.
>

> I often wish there was a modern emacs clone that dropped all these
> legacy features.

git clone git://git.savannah.gnu.org/emacs.git

any git clone is a fork!

> Who ever uses a toolbar?

I never do.

> Why don't the scrollbars work like normal?

I never use them.

> Why is the undo feature so ridiculous, instead of something more sane
> like undo-tree?

There's git for that. Seriously, who needs more than two undoes?

> Why isn't ido-mode enabled by default, and why doesn't it work on more
> completable prompts without a third party plugin?

ido-mode is unbearable, I don't use it.

[Steven Degutis]

Yes, any clone is a fork, but only the Privileged Few can understand
emacs' source code enough to do anything decent with it.

You can't seriously be suggesting that undo within a text editor is
not a useful feature?

I agree, ido-mode is unbearable in its default state. But with
ido-vertical-mode it's pretty great:
https://github.com/rson/ido-vertical-mode.el

[Pascal J. Bourguignon]

Steven Degutis <sbde...@gmail.com> writes:

> Any time I find myself editing files on a remote server, it's because
> I stupidly didn't prepare for the task properly and have to fix
> something "live". This is never a planned situation, and one I should
> really be avoiding rather than catering to. And in those rare times
> that I still find myself editing remote files, the server usually only
> has vim anyway, which gets the job done.

No, not on my servers. They never had vi or vim installed. Not since
1986. Even before booting the first installation of a system, emacs is
installed on. Otherwise how can you configure it?

[Pascal J. Bourguignon]

Steven Degutis <sbde...@gmail.com> writes:

> That's rather the other way you should ask: what's the use case
> of using a bitmap _graphic_ screen to edit _text_?
>
>
> Because then my syntax highlighting and color theme has access to
> some several million colors, not just 256. This, plus viewing it on a
> retina display, and suddenly the text I stare at all day looks quite
> beautiful.

That said, instead of complaining about terminal UI in emacs, you could
consider developing a CoreAnimation UI for emacs. If you can display
emacs windows nicer than SublimeText or Light Table, everybody'll be
happy. But that'll just be yet another display engine for emacs. This
won't change fundamentally the fact that it works mostly with text.

[Pascal J. Bourguignon]

Steven Degutis <sbde...@gmail.com> writes:

> That's rather the other way you should ask: what's the use case
> of using a bitmap _graphic_ screen to edit _text_?
>
>
> Because then my syntax highlighting and color theme has access to
> some several million colors, not just 256. This, plus viewing it on a
> retina display, and suddenly the text I stare at all day looks quite
> beautiful.

Well, sure, you have to justify the price of a retina display. Now
you're realizing that you're spending the day working with text, not
with images…

[Stefan Monnier]

> Seems like there's no real point in supporting terminal-mode in a text
> editor these days.

I think we'd drop terminal support if there was a good case *for* it.
But as it currently stands, before Emacs could benefit from dropping
support for terminal mode, we'd need a fair bit of change I think.

Admittedly, I have internalized most of the problems with terminal mode,
but I have a hard time thinking of cases where "oh, but it needs to also
work in terminal mode" was a significant impediment.

The only place that comes to mind is for choosing key bindings, but
even there, many other constraints (e.g. backward compatibility so as
not to anger all existing users; and being accessible for users of many
different keyboard layouts) tend to bring in the same problems anyway.


Stefan

[Dmitry Gutov]

Steven Degutis <sbde...@gmail.com> writes:

> I agree, ido-mode is unbearable in its default state. But with
> ido-vertical-mode it's pretty great:
> https://github.com/rson/ido-vertical-mode.el

a) ido-vertical-mode wastes screen estate (blank space to the right). I
wouldn't want to use that.

b) ido-mode is generally useful, but it makes some trivial operations
harder (like entering a file name of a new file, you have to press C-j
instead of RET). Also, `ido-completing-read''s interface is subtly
incompatible with `completing-read', hence the bag of tricks
`ido-ubiquitous' has to employ.

[Stefan Monnier]

> Why don't the scrollbars work like normal?

Probably because the difference is *much* smaller than the amount of
effort needed to mimick the "normal".


Stefan

[Peter Dyballa]

Am 05.05.2013 um 06:41 schrieb Steven Degutis:

> Because then my syntax highlighting and color theme has access to some
> several million colors, not just 256.

You cannot see the million differences. (And I doubt whether the monitors can really produce that many different colours in the real world.) *Trained* human eyes can differentiate between 128 colour tones and 130 saturation values. In the blue spectrum these eyes can percept 16 levels of light intensity, in the yellow spectrum it's 26 different levels. This makes up for 380,000 different perceptible colours. 16-bit colours are quite right for average computer users with colour monitors.

I'd wish GNU Emacs could read my mind so I wouldn't have to type typos!


Is it possible to invent the million names for the millions of theoretical colours? How many years would be needed? Would it be OK to use rather colour blind men for this job? Or should we aspire the maximum and engage sensitive women?

--
Greetings

Pete

Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
– Georges W. Bush

[Alan Mackenzie]

Hi, Steven!

Steven Degutis <sbde...@gmail.com> wrote:
> What's the use-case for having the terminal be able to act as an editor?

"The" terminal? There are several. I run Emacs in a Linux virtual
terminal, unless forced to use a GUI setup - e.g. for testing elisp.

Why? Because I want to run Emacs without distractions, without window
borders, without the mouse, without faffing around with fonts, and with my
Emacs frame filling the _whole_ screen. As somebody else said, why use a
graphic environment for manipulating pure text? A GUI is a general
unspecific mush, whereas a TUI is optimised for text.

Setting up Emacs on the virtual terminal is some work, agreed; you have
to extend the rather sparse keyboard layouts, and then teach Emacs how to
understand the new keyboard codes; working with several frames can be
awkward, so I wrote a little utility for key <Fn> to switch to frame n.
But the effort is worth it. To me, being able to run Emacs on a terminal
is one of its chief attractions.

> For me it's rather the other way around, I use the terminal within my
> editor (eshell).

You can do that on a terminal too. :-)

> Seems like there's no real point in supporting terminal-mode in a text
> editor these days.

Well, thanks very much! I believe that Richard Stallman uses Emacs on a
virtual terminal.

It is sometimes useful to have an editor available during installation of
a GUI, before that GUI is usable.

Are you suggesting you're willing to put in the work to remove terminal
support from Emacs? It'd be a lot of work. What would be the point?

> -Steven

--
Alan Mackenzie (Nuremberg, Germany).

[eniotna]

Hi,

How about pair-programming over ssh?
>From my standpoint, it's a killer feature!

tony

--
Antoine R. Dumont
https://github.com/ardumont
https://coderwall.com/ardumont
http://twitter.com/ardumont
http://adumont.fr/blog

On Sun, May 5, 2013 at 5:06 AM, Steven Degutis <sbde...@gmail.com> wrote:

> What's the use-case for having the terminal be able to act as an editor?
>

> For me it's rather the other way around, I use the terminal within my
> editor (eshell).
>

> Seems like there's no real point in supporting terminal-mode in a text
> editor these days.
>

> -Steven
>
>

[Pascal J. Bourguignon]

And in any case, what "normal" the usual "normal", or the new "normal"
of MacOSX Mountain Lion or iOS?

[Thien-Thi Nguyen]

() Steven Degutis <sbde...@gmail.com>
() Sun, 5 May 2013 00:43:37 -0500

Yes, any clone is a fork, but only the Privileged Few can understand
emacs' source code enough to do anything decent with it.

what privilege -- to have the source
(and time and obstinance to grok in full)!
still, decency forbids me, of course,
to drape my pushful whims as pull.

mayhaps there be a muddling middle,
where awkward (mis-)steps could warn, not err.
never opaque'd be my fuddling fiddle;
a tweak in alpha, to thwart despair.

i cannot count the ghosts that surround me;
they whisper lines of code and commentary.
through pregnant plant of secrets quite profoundly,
fear, was heavy, now hope, but momentary.

what privilege -- to have the source
(and nerve and indolance to shirk the view)!
still, cowardace spurs me on, of course,
to close my mind and mock the few.

thi

[Steven Degutis]

Quite beautiful.

[Steven Degutis]

By "normal", I mean how scrollbars work in the vast majority of
desktop GUIs since 1995.

[Mark Skilbeck]

On Sun, May 05, 2013 at 02:31:24PM -0500, Steven Degutis wrote:
> By "normal", I mean how scrollbars work in the vast majority of
> desktop GUIs since 1995.
>
> On Sun, May 5, 2013 at 9:27 AM, Pascal J. Bourguignon
> <p...@informatimago.com> wrote:

Which is how?

-mgsk

[Jason White]

Alan Mackenzie <a...@muc.de> wrote:

>Are you suggesting you're willing to put in the work to remove terminal
>support from Emacs? It'd be a lot of work. What would be the point?

Exactly. And if anyone is seriously proposing to remove terminal support,
could they also implement all of the necessary ATK interfaces to enable my
braille display to be used with Emacs under X11 and GTK? It works wonderfully
at the console and also over ssh connections, thanks to the terminal display
code in Emacs, removal of which would be a major regression for my use cases.

I should mention that I use Emacspeak for speech output and highly recommend
it; Emacspeak can run equally well in a terminal or under X, but for braille
access (using a refreshable braille device) Emacs really must be run in a
terminal session.

[ken]

On 05/05/2013 11:31 PM Jason White wrote:

> Alan Mackenzie <a...@muc.de> wrote:
>
>> Are you suggesting you're willing to put in the work to remove terminal
>> support from Emacs? It'd be a lot of work. What would be the point?
>

> Exactly. And if anyone is seriously proposing to remove terminal support,
> could they also implement all of the necessary ATK interfaces to enable my
> braille display to be used with Emacs under X11 and GTK? It works wonderfully
> at the console and also over ssh connections, thanks to the terminal display
> code in Emacs, removal of which would be a major regression for my use cases.
>
> I should mention that I use Emacspeak for speech output and highly recommend
> it; Emacspeak can run equally well in a terminal or under X, but for braille
> access (using a refreshable braille device) Emacs really must be run in a
> terminal session.

Occasionally I need to work on a remote server which doesn't have X
running and have to do extensive editing, not trivial enough to use vi.
So, yes, in those instances it's nice not to have to learn a new
editor-- which would be the only alternative.

Also, I've run emacs in batch mode to extensively edit thousands of
files non-interactively all "at once", something which would have taxed
my sed, awk, and grep skills and required a much longer time to develop
than it did using emacs.

Emacs isn't simply an editor in the sense that Word is an editor.
Stallman, in fact, prefers the term "text processor" to describe emacs,
and as the people above indicate, it's a very extensible one at that.

[Peter Dyballa]

Am 06.05.2013 um 11:52 schrieb ken:

> Occasionally I need to work on a remote server which doesn't have X running and have to do extensive editing

You can also use your local X server…

--
Greetings

Pete

The light at the end of the tunnel has been turned off due to budget cuts.

[Bastien]

eniotna <enio...@gmail.com> writes:

> How about pair-programming over ssh?
> From my standpoint, it's a killer feature!

Indeed.

Phil Hagelberg hacked this, which looks pretty neat:
https://syme.herokuapp.com/

--
Bastien

[Pascal J. Bourguignon]

As for the usage patterns, I should mention that it occurs often enough
that I use both terminal frames and X11 frames.

(And if Cocoa emacs was able to do it, I would also use X11 or terminal
frames at the same time with a Cocoa window).

Since I reboot emacs only when I need to reboot the underlying kernel, I
connect to my emacs instances thru any kind of interface. I have on my
desktop a MacOSX, a Linux and a MS-Windows-7 system, and I may also
connect to it remotely. Therefore I may want to make frames from any of
those interfaces to the same emacs instance.

[Joost Kremers]

Alan Mackenzie wrote:
> Hi, Steven!
>
> Steven Degutis <sbde...@gmail.com> wrote:
>> What's the use-case for having the terminal be able to act as an editor?
>
> "The" terminal? There are several. I run Emacs in a Linux virtual
> terminal, unless forced to use a GUI setup - e.g. for testing elisp.
>
> Why? Because I want to run Emacs without distractions, without window
> borders, without the mouse, without faffing around with fonts, and with my
> Emacs frame filling the _whole_ screen. As somebody else said, why use a
> graphic environment for manipulating pure text? A GUI is a general
> unspecific mush, whereas a TUI is optimised for text.
>
> Setting up Emacs on the virtual terminal is some work, agreed;

Then why bother, if you can have a full-screen Emacs without scroll bar,
menu bar, tool bar, window borders etc. but *with* all the "ease" of
running Emacs under X?

Not that I'd be in favour of removing support for using Emacs in a
(virtual) terminal, though. I use it myself sometimes for testing Elisp
code in a VM (my 5yo computer would grind to a halt if I'd run X in a VM...)


--
Joost Kremers joostk...@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

[Cecil Westerhof]

Op zondag 5 mei 2013 05:43 CEST schreef Chad Brown:

> Remote editing on systems that have SSH but not X11. Android and iOS tablets
> and phones are pretty common.

That is good to know. It only works with a real keyboard. So I should
buy one and then I could use Emacs on my Android.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[Hugh Lawson]

I use "sudo emacs -nw <filename>" in terminal to edit configuration
files with super-user permissions. I know about tramp, but as a
single-desktop Linux user, I've not had much occasion to use it to edit
remote files. Hence I forget the tramp commands. "emacs -nw" is easy
to remember for me.

[Nicolas Richard]

Hugh Lawson <hu.l...@gmail.com> writes:

> I use "sudo emacs -nw <filename>" in terminal to edit configuration

This runs emacs with su power, which is not so good. I suggest using
$ sudoedit <filename>
with the (EDITOR or) VISUAL environment variable set
to "emacsclient" (or to "emacsclient -a=" or "emacsclient -a= -t", or
"emacs" if you really prefer a new emacs session to be started.).

(And, going back to the subject, I also use emacs over ssh regularly
together with emacsclient, and don't have an internet connection good
enough to create X frames over ssh.)

--
Nico.

[Andrea Venturoli]

On 05/06/13 11:56, Peter Dyballa wrote:
>
> Am 06.05.2013 um 11:52 schrieb ken:
>
>> Occasionally I need to work on a remote server which doesn't have X running and have to do extensive editing
>

> You can also use your local X server�

Which is some orders of magnitude slower...

bye
av.

[Steinar Bang]

>>>>> Jai Dayal <daya...@gmail.com>:

> I do. I use it mostly over ssh on supercomputers.. no need to forward X11
> sessions and all that junk. I would say I never use emacs without the
> terminal.

And I do, in mosh sessions from my netbook. http://mosh.mit.edu/

[Bob Proulx]

Nicolas Richard wrote:

> Hugh Lawson writes:
> > I use "sudo emacs -nw <filename>" in terminal to edit configuration
>

> This runs emacs with su power, which is not so good.

I disagree. There is nothing wrong with it. It is no different than:

# emacs -nw

And surely everyone on this list would agree that emacs is a good
editor for root to use.

Bob

[Pascal J. Bourguignon]

Yes. However, you must be conscious of the theorical possibility of
emacs lisp viruses thru file and directory local variables.

If you find-file in a directory where a malicious user has written a
.dir-locals.el file, he could theorically take advantage of it to root
you. Of course, normally emacs ask permission to evaluate a form, or to
set any variable he doesn't know to be safe. But if you type y or !
carelessly, you can be hosed.

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

You can take the lisper out of the lisp job, but you can't take the lisp out
of the lisper (; -- antifuchs

[Bob Proulx]

Pascal J. Bourguignon wrote:

> Bob Proulx writes:
> > # emacs -nw
> >
> > And surely everyone on this list would agree that emacs is a good
> > editor for root to use.
>
> Yes. However, you must be conscious of the theorical possibility of
> emacs lisp viruses thru file and directory local variables.

But emacs will always ask you if it should proceed due to that issue.
It will never do it automatically. It isn't intrinsically insecure.

> If you find-file in a directory where a malicious user has written a
> .dir-locals.el file, he could theorically take advantage of it to root
> you. Of course, normally emacs ask permission to evaluate a form, or to
> set any variable he doesn't know to be safe. But if you type y or !
> carelessly, you can be hosed.

But only if you approve using the local setting. And you would need
to be exposed to hostile user attack in order to trigger it.

If it is your laptop with you as the only user that is unlikely and
answer yes without thinking probably won't hurt you. You can think
less. You are more safe on your own machine where only you work.

If you are an admin of a university system with clever kids poking at
the system with social engineering attacks then you need to be more
vigilant. But then you should always be vigilant in a hostile
environment such as those.

Bob

[Nicolas Richard]

Bob Proulx <b...@proulx.com> writes:
> I disagree. There is nothing wrong with it. It is no different than:
>
> # emacs -nw

I would not do that either, not only because emacs is a huge beast which
can have bugs, but most importantly because I don't trust myself in not
doing anything harmful inadvertantly after some time [*]. Anyway we can
agree to disagree (and/or continue off list if you wish). I simply
wanted to point out the existence of sudoedit which I found a very smart
idea when I discovered it.

[*] I sometimes wish I could use some programs as separate users and
only when needed give one of them the right on a given set of
files/directories. Unfortunately my skills are too limited to be able to
use such a setup (and it's overkill compared to the very limited
security I enforce in other areas on my computer). But if anyone reading
this has hints on how to achive that setup or anything similar,
suggestions are very welcome and my mailbox is open.

--
Nico.

[Steven Degutis]

So, I was going to link to certain xkcd comics that this thread
reminded me of, to point out the vanity of these excessive concerns
over security.

But then I clicked to the next comic. And the next. Each one evoked a
more keen sense of existential futility than the last. So I asked
myself, "really, what's the point in replying?"

True story.

[Pascal J. Bourguignon]

"Nicolas Richard" <theonewith...@yahoo.fr> writes:

> Bob Proulx <b...@proulx.com> writes:
>> I disagree. There is nothing wrong with it. It is no different than:
>>
>> # emacs -nw
>
> I would not do that either, not only because emacs is a huge beast which
> can have bugs, but most importantly because I don't trust myself in not
> doing anything harmful inadvertantly after some time [*].

Yes, but then, I *know* I will do something harmful by using a different
editor than the one I'm used to when occasionnaly editing as root, hence
my relentless destruction of any other editor than emacs on systems I
install, even before the first boot.


No, the only real risk with emacs, is that it's so agreable to use, that
you may forgot you're logged as root. For this, I have:

(when (= (user-uid) 0)
(set-background-color "black")
(set-foreground-color "red"))

in my .emacs files…

[Stefan Monnier]

> But emacs will always ask you if it should proceed due to that issue.
> It will never do it automatically. It isn't intrinsically insecure.

Well, that depends how paranoid you are. It used to be intrinsically
insecure (only prompting the user for things known to be dicey) and has
been improved over the years (always prompting unless told that it's
safe), but there are so many variables marked as "safe" that might be
used in unexpected ways by so many packages that "intrinsically secure"
sounds naive.

More specifically, I'd be *very* surprised if there aren't any "big
security holes" waiting to be exploited in Emacs.

> And you would need to be exposed to hostile user attack in order to
> trigger it.

Yes. I think that's what keeps you safe.


Stefan "who uses Zile when running as root"

[Bob Proulx]

Stefan Monnier wrote:

> Bob Proulx wrote:
> > But emacs will always ask you if it should proceed due to that issue.
> > It will never do it automatically. It isn't intrinsically insecure.
>
> Well, that depends how paranoid you are. It used to be intrinsically
> insecure (only prompting the user for things known to be dicey) and has
> been improved over the years (always prompting unless told that it's
> safe), but there are so many variables marked as "safe" that might be
> used in unexpected ways by so many packages that "intrinsically secure"
> sounds naive.

I didn't say "intrinsically secure". I said, "It isn't intrinsically INsecure."
Which isn't the same thing. A couple of quotes come to mind.

"It is hard to make things foolproof because fools are so clever."

"You can make things foolproof. But you can't make them damn foolproof."

:-)

> More specifically, I'd be *very* surprised if there aren't any "big
> security holes" waiting to be exploited in Emacs.

Show me the bug report. Unless there is a bug report on *something*,
anything, then I call shenanigans and say it is nothing but spreading
FUD (fear, uncertainty, doubt). Because just using the computer is a
security hole.

Which reminds me of another posting. There is only one truly secure
computer system.

http://www.ranum.com/security/computer_security/papers/a1-firewall/index.html

> Stefan "who uses Zile when running as root"

I don't know. I heard on the Internet that Zile has security
vulnerabilities. (Part of the FUD, counter-FUD, campaign. I really
don't have anything against Zile.)

Bob

[Jonathan Groll]

On Wed, 08 May 2013 21:15:10 -0400, Stefan Monnier <mon...@iro.umontreal.ca> wrote:

> > But emacs will always ask you if it should proceed due to that issue.
> > It will never do it automatically. It isn't intrinsically insecure.
>
> Well, that depends how paranoid you are. It used to be intrinsically
> insecure (only prompting the user for things known to be dicey) and has
> been improved over the years (always prompting unless told that it's
> safe), but there are so many variables marked as "safe" that might be
> used in unexpected ways by so many packages that "intrinsically secure"
> sounds naive.
>

> More specifically, I'd be *very* surprised if there aren't any "big
> security holes" waiting to be exploited in Emacs.
>

> > And you would need to be exposed to hostile user attack in order to
> > trigger it.
>
> Yes. I think that's what keeps you safe.
>
>

> Stefan "who uses Zile when running as root"

Sure, you can forget you're root, (in all cases), but dired as root is
maybe more than just a nice to have. For instance, it makes it easier
to browse the system logfiles, etc. I can't say that I'd never use
Emacs as root - it is simply too useful, and the trade-off of potential
security risk versus utility seems to me to be one that I'm willing to
make.

Cheers,
Jonathan
--
jjg: Jonathan J. Groll : groll co za
has_one { :blog => "http://bloggroll.com" }
Any other Disclaimer in this mail is Wrong.

[Thorsten Jolitz]

"Pascal J. Bourguignon" <p...@informatimago.com> writes:

> No, the only real risk with emacs, is that it's so agreable to use, that
> you may forgot you're logged as root. For this, I have:
>
> (when (= (user-uid) 0)
> (set-background-color "black")
> (set-foreground-color "red"))
>
> in my .emacs files…

I have this in my (minimal) init file for Emacs root sessions, which is
quite nice since it keeps the e.g. black background and wheat foreground
colors and only adds a red header line at the top of the buffer. I
copied it from somewhere, probably Fabrice Niessen's .emacs, but I'm not
sure about it.

,--------------------------------------------------------------------
| ;; ** Warning about being 'root'
|
| (message "emacs-ESU-script root warning ...")
|
| (defface find-file-root-header-face
| '((t (:foreground "white" :background "red3")))
| "*Face use to display header-lines for files opened as root.")
|
| (defun find-file-root-header-warning ()
| "*Display a warning in header line of the current buffer.
| This function is suitable to add to `find-file-root-hook'."
| (let* ((warning "WARNING: EDITING FILE WITH ROOT PRIVILEGES!")
| (space (+ 6 (- (frame-width) (length warning))))
| (bracket (make-string (/ space 2) ?-))
| (warning (concat bracket warning bracket)))
| (setq header-line-format
| (propertize warning 'face 'find-file-root-header-face))))
|
| (add-hook 'find-file-hook 'find-file-root-header-warning)
| (add-hook 'dired-mode-hook 'find-file-root-header-warning)
`--------------------------------------------------------------------

--
cheers,
Thorsten

[Peter Dyballa]

Am 08.05.2013 um 22:51 schrieb Nicolas Richard:

> [*] I sometimes wish I could use some programs as separate users and
> only when needed give one of them the right on a given set of
> files/directories.

Role-based access control: http://en.wikipedia.org/wiki/RBAC. This article has a large "See also" list. Don't overlook SELinux!

--
Greetings

Pete

When in doubt, use brute force.
– Ken Thompson

[Peter Dyballa]

Am 09.05.2013 um 01:21 schrieb Pascal J. Bourguignon:

> Yes, but then, I *know* I will do something harmful by using a different
> editor than the one I'm used to when occasionnaly editing as root, hence
> my relentless destruction of any other editor than emacs on systems I
> install, even before the first boot.

GNU Emacs is a bit ore than just a plain editor. It can perform a lot more than vi, nano, pico etc. Therefore its use is more dangerous, at least in theory.

--
Greetings

Pete

Theory and practice are the same, in theory, but, in practice, they are different.

[Tamas Papp]

On Thu, May 09 2013, Jonathan Groll wrote:

> Sure, you can forget you're root, (in all cases), but dired as root is
> maybe more than just a nice to have. For instance, it makes it easier
> to browse the system logfiles, etc. I can't say that I'd never use
> Emacs as root - it is simply too useful, and the trade-off of potential
> security risk versus utility seems to me to be one that I'm willing to
> make.

I have similar preferences, but instead of running Emacs as root, I use
tramp/su (or sudo on Ubuntu machines). I am not an expert about these
issues, but I imagine that it is safer than running Emacs as root.

Best,

Tamas

[Luca Ferrari]

On Sun, May 5, 2013 at 6:31 AM, Pascal J. Bourguignon
<p...@informatimago.com> wrote:
>
> Of course, every day!

>
>
> Steven Degutis <sbde...@gmail.com> writes:
>
>> What's the use-case for having the terminal be able to act as an editor?
>

> That's rather the other way you should ask: what's the use case of using
> a bitmap _graphic_ screen to edit _text_?
>


+1

On my desktop I use emacs within X window, even if I've disabled
almost any toolbar and menubar and don't use the mouse at all.
However, when connected to a remote server via SSH, being able to run
emacs is a killing feature to me.
Moreover, what I found very interesting to do is to start emacs on the
remote machine and live within (i.e., use eshell for other tasks).

Luca

[Jai Dayal]

Um... what exactly can emacs do that vim can't? Or is vim not included in
"etc"?

On May 9, 2013 2:38 AM, "Peter Dyballa" <Peter_...@web.de> wrote:

>
> Am 09.05.2013 um 01:21 schrieb Pascal J. Bourguignon:
>

> > Yes, but then, I *know* I will do something harmful by using a different
> > editor than the one I'm used to when occasionnaly editing as root, hence
> > my relentless destruction of any other editor than emacs on systems I
> > install, even before the first boot.
>

[notbob]

On 2013-05-09, Jai Dayal <daya...@gmail.com> wrote:
> Um... what exactly can emacs do that vim can't? Or is vim not included in
> "etc"?

Edit in a single mode.

[Peter Dyballa]

Am 09.05.2013 um 15:39 schrieb Jai Dayal:

> Um... what exactly can emacs do that vim can't?

Visit remote sites, work like Norton Commander, have an interactive calendar displayed… (And I'm not using the whole potential of GNu Emacs. And vi/vim, too.)

--
Greetings

Pete

Cyanide is so poisonous that one drop of it on a dog's tongue will kill the strongest man.

[Jai Dayal]

I'm not sure what you mean "visit remote sites"? I do that with Vim all the
time.

Vim has an interactive calendar extension

"Norton Commander,"

That's an extension that could be done in Vim. It does seem like Vim has an
extension for that.

So, your argument boils down to "There are some emacs *extensions* I like
that Vim may or may not have exactly", not that Vim can't do them (they
both allow for programmable extensions, after all)

[Jai Dayal]

That's not functionality, though. That's usability. If your argument
against Vim is "well, it's not emacs" then that doesn't answer the question
as we're talking about functionality, not usability.

[Luca Ferrari]

On Thu, May 9, 2013 at 3:39 PM, Jai Dayal <daya...@gmail.com> wrote:
> Um... what exactly can emacs do that vim can't? Or is vim not included in
> "etc"?

Well, probably emacs can run vim....;)
Emacs is a lisp interpreter that happens to have an editor running as
default application!

Luca

[Jai Dayal]

Emacs doesn't really run Vim.. it has Viper mode, but it's not nearly Vim.
Similarly, in Vim, you can run emacs mode.

[Óscar Fuentes]

Jai Dayal <daya...@gmail.com> writes:

> Emacs doesn't really run Vim.. it has Viper mode, but it's not nearly Vim.

http://gitorious.org/evil/pages/Home

Not Vim *yet*, but converging fast.

> Similarly, in Vim, you can run emacs mode.

Does it run Gnus, Slime, magit...?

[Jai Dayal]

You just admitted not yet Vim but then want emacs mode in vim to be exactly
emacs? At any rate, that functionality is available in Vim.

So again, the initial statement doesn't hold, at all.

[Jai Dayal]

What's viper mode supposed to be in Emacs? You mean key bindings? All Vim
modes really are are just key sequences.
On May 9, 2013 10:19 AM, "Hongxu Chen" <leftco...@gmail.com> wrote:

>
> What's Emacs mode supposed to be in Vim?
>
> You mean the keybindings?

>
> Jai Dayal <daya...@gmail.com> writes:
>
> > Emacs doesn't really run Vim.. it has Viper mode, but it's not nearly
> Vim.

> > Similarly, in Vim, you can run emacs mode.
> >
> >

> > On Thu, May 9, 2013 at 12:00 PM, Luca Ferrari <fluc...@infinito.it>
> wrote:
> >
> >> On Thu, May 9, 2013 at 3:39 PM, Jai Dayal <daya...@gmail.com> wrote:
> >> > Um... what exactly can emacs do that vim can't? Or is vim not
> included
> >> in
> >> > "etc"?
> >>
> >> Well, probably emacs can run vim....;)
> >> Emacs is a lisp interpreter that happens to have an editor running as
> >> default application!
> >>
> >> Luca
> >>
> >>
>

> --
> Regards,
> Hongxu Chen
>

[Hongxu Chen]

Apart from those lisp-family program modes, I like emacs better since
there are more elaborate configurations for me, directory local
variables for instance, which makes emacs a more modern IDE.

Emacs also has more powerful buffer handling features than Vim, although
Vim has better built-in Window and Tab operations.

[Hongxu Chen]

What's Emacs mode supposed to be in Vim?

You mean the keybindings?

Jai Dayal <daya...@gmail.com> writes:

> Emacs doesn't really run Vim.. it has Viper mode, but it's not nearly Vim.
> Similarly, in Vim, you can run emacs mode.
>
>
> On Thu, May 9, 2013 at 12:00 PM, Luca Ferrari <fluc...@infinito.it> wrote:
>

[Óscar Fuentes]

Jai Dayal <daya...@gmail.com> writes:

> You just admitted not yet Vim but then want emacs mode in vim to be exactly
> emacs? At any rate, that functionality is available in Vim.
>
> So again, the initial statement doesn't hold, at all.

There is a huge difference among "not 100% vim yet" (vim emulation on
Emacs) with "the most simple features forever" (Emacs emulation on Vim)

And now I wonder why I'm arguing on yet another stupid editor flamewar,
considering that I'm a happy user of Emacs and Vi(m), currently using
Emacs+vimpulse and enjoying the best of both worlds.

[Jai Dayal]

Emacs mode on vim is not just basic features.

The point is: the author (or anyone else) cannot accurately defend the
original statement, thus the original author should be banned for
deliberately spreading false information.

For the record, I do not use Vim.

[Óscar Fuentes]

Óscar Fuentes <o...@wanadoo.es> writes:

> considering that I'm a happy user of Emacs and Vi(m), currently using
> Emacs+vimpulse and enjoying the best of both worlds.

__^^^^^^^^^^^^^^
Emacs+Evil. Vimpulse is dead.

[Jay Belanger]

> Um... what exactly can emacs do that vim can't?

Calculus.

[Óscar Fuentes]

Jai Dayal <daya...@gmail.com> writes:

> Emacs mode on vim is not just basic features.

So it can run Elisp?

> The point is: the author (or anyone else) cannot accurately defend the
> original statement, thus the original author should be banned for
> deliberately spreading false information.

The information benefited Emacs over Vim, so the original author
deserves praise on this mailing list, not being the accuracy of the
information a relevant consideration.

OTOH, you can ban him on the vim mailing lists (again, not being the
accuracy of the information a relevant consideration.)

> For the record, I do not use Vim.

Ah, you are the famed editor flamewar fairness masked vigilante.

:-)

[Jai Dayal]

Elisp is a language. Vim has a language of its own. The functionality is
no different and both are Chomsky NF languages. You Re arguing keystroke
usability not functionality. Every argument here has been about
keystrokes, not functionality.

[Óscar Fuentes]

Jai Dayal <daya...@gmail.com> writes:

> Elisp is a language. Vim has a language of its own. The functionality is
> no different and both are Chomsky NF languages.

Right! It always annoyed me that people wasted time creating all those
languages when you can program in raw machine code.

> You Re arguing keystroke usability not functionality.

Uh?

> Every argument here has been about keystrokes, not functionality.

Perhaps in your head.

[Steven Degutis]

Dear mailing list:

I'm terribly sorry to have started a pointless flame war. Please forgive me.

How about we all just agree that we all think differently about this, and
drop this thread?

-Steven

[Peter Dyballa]

Am 09.05.2013 um 17:35 schrieb Jai Dayal:

> So, your argument boils down to "There are some emacs *extensions* I like
> that Vim may or may not have exactly", not that Vim can't do them (they
> both allow for programmable extensions, after all)

To be correct: I use vi/vim for simple file editing and I use GNU Emacs for some things. Not knowing that vim has so many extensions and coming from vi and being used to used I never had the idea something else than a very good editor. So it's pure ignorance that led to my statement, and I have to commit that it's theoretically possible (in theory, because I never have used such a pimped up vi or vim) that GNU Emacs and vi/vim are dangerous because a super-user can make mistakes when using them which can damage the system. OK?

--
Greetings

Pete

If the majority of cooking accidents happen in the kitchen, then why don't we just cook in other rooms?

[Peter Dyballa]

Am 09.05.2013 um 17:35 schrieb Jai Dayal:

> I'm not sure what you mean "visit remote sites"?

With TRAMP for example you can log in to other computers and edit files there or perform some file exchange or use a shell on that remote system.


BTW, why are you reading this list when you don't know the GNU Emacs basics? They're documented in the documentation inside GNU Emacs and here in this list you mostly receive calls for help or reports about possible bugs. It happens quite rarely that GNU Emacs basics are explained hereby someone… – or two.

--
Greetings

Pete

We need a president who's fluent in at least one language.
– Buck Henry

[Jai Dayal]

You can do that with Vim easily. I was double checking because I was
astonished by the sheer ignorance of that statement.

[Jai Dayal]

And BTW, you said "visit", not edit. Visit does not strictly mean edit.
You are just as ambiguous as you are inaccurate.

[Jay Belanger]

Jai Dayal <daya...@gmail.com> writes:

> And BTW, you said "visit", not edit. Visit does not strictly mean edit.

From the Emacs manual:
"Visiting" a file means reading its contents into an Emacs buffer so
you can edit them. Emacs makes a new buffer for each file that you
visit.

> You are just as ambiguous as you are inaccurate.

Technically true, since he was both unambiguous and accurate.

[Peter Dyballa]

Am 09.05.2013 um 21:01 schrieb Jai Dayal:

> You can do that with Vim easily. I was double checking because I was
> astonished by the sheer ignorance of that statement.

OK! But anyway, I'd prefer a simple vi as of 20 or 30 years ago. This gives me just what *I* want.

And because of my very wide vim ignorance I'll stop commenting on it!

--
Greetings

Pete

Isn't vi that text editor with two modes... one that beeps and one that corrupts your file?
– Dan Jacobson, on comp.os.linux.advocacy

[Óscar Fuentes]

Jai Dayal <daya...@gmail.com> writes:

> And BTW, you said "visit", not edit. Visit does not strictly mean edit.

> You are just as ambiguous as you are inaccurate.

In Emacs parlance, "visiting" means loading the contents of a file into
a buffer for some purpose (reading, editing, processing, whatever.)

On this mailing list, saying that Emacs can visit a file on a remote
machine is more precise than saying that it can edit that same file.

TRAMP is much more than visiting remote files. It is a framework for
working with a local Emacs instance on a remote machine. For example:
with your local Emacs visit a remote source file, then compile it and
run a gdb session as you would do if it were a local file.

[Jai Dayal]

Point taken. The manual does indeed define visit.

However Vim offers the exact same functionality.

[Jai Dayal]

He was not accurate because he stated this could not be done in Vim.

[Jay Belanger]

> He was not accurate because he stated this could not be done in Vim.

You were griping about his (accurate) use of the work "visit" when you
called him inaccurate.

[rusi]

On May 9, 9:46 pm, Jai Dayal <dayals...@gmail.com> wrote:
> Emacs mode on vim is not just basic features.

Not wishing to add to the flames here but genuinely ask a question…

As a teacher of programming, I like to allow students to be free about
things that are distant from programming.
Also by default I use emacs.

Now as for program editing I expect that vim has the mode-
functionality that emacs has.
I am specifically interested in inferior buffers ie derivatives of
comint mode:

Is it possible to run the python interpreter or the haskell
interpreter under vi?
Last I looked it was not.

In case this seems to add to the flames, here's my recent mooc course
offering on haskell+python:
https://moocfellowship.org/submissions/the-dance-of-functional-programming-languaging-with-haskell-and-python
wherein I say that I use emacs but participants can use what they
like.

[Jai Dayal]

Vim has a python interpreter.. I think even natively at this point. Vim
also has the Superior Haskell Interaction Mode (SHIM) extension.

The point of Vim and Emacs is that they are extendable. You can get them to
do arbitrary things. There isn't one thing that emacs does inherently that
is impossible to do with Vim, and visa-vera. That's the point I'm trying to
get at.

[PJ Weisberg]

On May 9, 2013 2:09 PM, "Jai Dayal" <daya...@gmail.com> wrote:
> On May 9, 2013 2:06 PM, "Jay Belanger" <jay.p.b...@gmail.com> wrote:
>

> He was not accurate because he stated this could not be done in Vim.

Pish-posh! Can Vim "read[ a file's] contents into an Emacs buffer"? I
think NOT.

This thread should be retitled "Does anyone really use Vim?". I can't see
any reason to support Vim on a modern Emacs-based system, and I purpose
that everyone henceforth cease to put any effort into supporting it. :-)

[Stefan Monnier]

> This thread should be retitled "Does anyone really use Vim?". I can't see
> any reason to support Vim on a modern Emacs-based system, and I purpose
> that everyone henceforth cease to put any effort into supporting it. :-)

You mean I should mark Vim as obsolete in the upcoming Emacs-25?


Stefan

[Jai Dayal]

I think more people use Vim than emacs. Not sure if there was any
scientific poll done on it.

On Sat, May 11, 2013 at 12:01 AM, PJ Weisberg <pjwei...@gmail.com> wrote:

> On May 9, 2013 2:09 PM, "Jai Dayal" <daya...@gmail.com> wrote:
> > On May 9, 2013 2:06 PM, "Jay Belanger" <jay.p.b...@gmail.com> wrote:
> >

> > He was not accurate because he stated this could not be done in Vim.
>

> Pish-posh! Can Vim "read[ a file's] contents into an Emacs buffer"? I
> think NOT.

[Luca Ferrari]

On Thu, May 9, 2013 at 6:02 PM, Jai Dayal <daya...@gmail.com> wrote:
> Emacs doesn't really run Vim.. it has Viper mode, but it's not nearly Vim.
> Similarly, in Vim, you can run emacs mode.

I was joking, I was not meaning the vim-like mode, just that Emacs is
so powerful that you can run a shell, a directory browser, a database
explorer, and so on...so you can pretty much run any command in Emacs.

Luca

[Jai Dayal]

Again, Vim does that too. I'm just shocked and offended that people here
don't know basics.

[Peter Dyballa]

Am 11.05.2013 um 20:14 schrieb Jai Dayal:

> I'm just shocked and offended that people here don't know basics.

Well, this is a GNU Emacs related list. Shouldn't it be enough to know the basics of writing and reading, a bit of GNU Emacs, and having a problem to be solved? Best of course when this problem is also GNU Emacs related!

What is your problem?

--
Greetings

Pete

Imbecility, n.:
A kind of divine inspiration, or sacred fire affecting censorious critics of this dictionary.
– Ambrose Bierce: _The Devil's Dictionary_

[Jay Belanger]

Jai Dayal <daya...@gmail.com> writes:

> Again, Vim does that too. I'm just shocked and offended that people here
> don't know basics.

Basics of what? Basics of vim, on an emacs list?
You are easily shocked, and you've already demonstrated that you are
eager to be offended.
Since you know the basics of vim; can vim do Calculus?

[Jai Dayal]

If one does not know the basics of vim then one should not make such strong
incorrect statements. Yes Vim can do calculus

[Jay Belanger]

Jai Dayal <daya...@gmail.com> writes:

> If one does not know the basics of vim then one should not make such strong
> incorrect statements.

Like I said, eager to be offended.

> Yes Vim can do calculus

Cool; I didn't know that. How does vim do it?
Honest question: emacs can do
M-: (calc-eval "integ(x^2*exp(x),x)")
to get
"x^2 exp(x) + 2 exp(x) - 2 x exp(x)"
How does vim do that?

[Jai Dayal]

I understand that you did a simple google search and couldn't find what you
were looking for (vim in calculus actually means something else), so if
you're not willing to do a little extra work and expect me to prove the
most basic trivial things, I'm going to ask you to put something on the
line, i.e., when I show you Vim's calculus plugins, you never post on this
mailing list again. deal?

[Jay Belanger]

> I understand that you did a simple google search and couldn't find what you
> were looking for

You understand wrong. I use Calc a lot in Emacs.
But then you aren't really trying to understand anything; you are merely
throwing a hissy fit.

> (vim in calculus actually means something else)

So can vim integrate x^2*e^x?

> so if you're not willing to do a little extra work and expect me to
> prove the most basic trivial things,

I expect you to prove that vim can do integrals; no problem for you,
since it is basic and trivial. I honestly would be interested in vim
doing that so I could play around with it. I really hope it can, but
your ill-informed tantrum gives me the impression that it can't.

> I'm going to ask you to put something on the line, i.e., when I show
> you Vim's calculus plugins,

We were talking about vim, not plugins. Can vim do it or not?
If so, show me how to get vim to do it. I have vim installed on my
computer; that's all I need, right? How to I get it to do an integral?
I showed you how to get emacs to do it, now your turn.