launch a program in an arbitrary frame

launch a program in an arbitrary frame

[Hikaru Ichijyo]

A newbie question (getting more hooked on Emacs):

I often run ERC to connect to IM services via a local Bitlbee daemon.
It works best running in its own frame, so I know when people are
talking to me without having to flip through all my buffers.  (A window
doesn't seem to be sufficient, since Gnus keeps changing the window
layout to its Summary/Article split, and the only way I've found to deal
with that is to keep programs whose layout I care about in separate
frames.)

Anyway, it's redundant to have to manually put ERC in its own frame
every time I launch it.

I have somethink like this bound to a key:

  (erc :server "localhost")

Some programs have the ability to launch in a new frame built into them,
but shouldn't you be able to do that with almost any program?  If I
wanted to run the above in an 80x24 frame at a particular X coordinate,
how would I say that in Elisp?

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Vaidheeswaran C]

On Saturday 18 July 2015 08:51 AM, Hikaru Ichijyo wrote:
> A newbie question (getting more hooked on Emacs):
> 
> I often run ERC to connect to IM services via a local Bitlbee daemon.
> It works best running in its own frame, so I know when people are
> talking to me without having to flip through all my buffers.  (A window
> doesn't seem to be sufficient, since Gnus keeps changing the window
> layout to its Summary/Article split, and the only way I've found to deal
> with that is to keep programs whose layout I care about in separate
> frames.)
> 
> Anyway, it's redundant to have to manually put ERC in its own frame
> every time I launch it.
> 
> I have somethink like this bound to a key:
> 
>   (erc :server "localhost")
> 
> Some programs have the ability to launch in a new frame built into them,
> but shouldn't you be able to do that with almost any program?  If I
> wanted to run the above in an 80x24 frame at a particular X coordinate,
> how would I say that in Elisp?
>

I don't use erc or frames.  But this is how I would go about exploring
more on the topic.

----------------------------------------------------------------

Did you try #emacs on irc.freenode.net?  They are likely to have a
ready solution for you.

    http://www.emacswiki.org/emacs?ErcBasics

----------------------------------------------------------------

    M-x load-library erc
    M-x apropos erc frame

I get

    Type RET on a type label to view its full documentation.

    erc-frame-alist
      User option: Alist of frame parameters for creating erc frames.
      Properties: standard-value custom-type custom-requests
		  variable-documentation
    erc-frame-dedicated-flag
      User option: Non-nil means the erc frames are dedicated to that
		   buffer.
      Properties: standard-value custom-type custom-requests
		  variable-documentation
    erc-reuse-frames
      User option: Determines whether new frames are always created.
      Properties: standard-value custom-type custom-requests
		  variable-documentation
    supercite-frames
      Properties: custom-loads

----------------------------------------------------------------

1. Create a new frame.
2. Open erc there.

Or use the following which more or less does the same thing.


    (defun erc-other-frame (&optional server)
      (interactive (list "irc.freenode.net"))
      (switch-to-buffer-other-frame (erc :server server)))

M-x erc-other-frame

----------------------------------------------------------------

Once you have hand-adjusted the new frame, get it's configuration.

If you do

    M-x pp-eval-expression RET (current-frame-configuration) RET

it tells you about your current frame.  You may want to steal top,
left, width, height and name parameters.

----------------------------------------------------------------

Once you have obtained the configuration, plug those values in to erc
frame alist.

----------------------------------------------------------------

You can also experiment with what are called framesets.  Try doing
what these nodes tell you

    C-h k C-x r f
    C-h K C-x r f

(Note the case of letter `k')

----------------------------------------------------------------

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
writes:

> (defun erc-other-frame (&optional server)
>   (interactive (list "irc.freenode.net"))
>   (switch-to-buffer-other-frame (erc :server server)))

Here is another version which lets you input a server
when calling it interactively and not just from Elisp.
If you hit RET you'll get the default value just
the same.

(defun erc-other-frame (&optional server)
  (interactive (list
                (let ((default "irc.freenode.net"))
                  (read-string (format "Server (%s): " default)
                               nil nil default) )))
  (switch-to-buffer-other-frame (erc :server server)) )

Personally, I don't do frames, so this comment is only
about the interactive stuff.

Here is my ERC setup, so far:

    http://user.it.uu.se/~embe8573/conf/emacs-init/erc-my.el

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: launch a program in an arbitrary frame

[Vaidheeswaran C]

On Saturday 18 July 2015 08:51 AM, Hikaru Ichijyo wrote:
> A newbie question (getting more hooked on Emacs):
> 
> I often run ERC to connect to IM services via a local Bitlbee daemon.
> It works best running in its own frame, so I know when people are
> talking to me without having to flip through all my buffers.  (A window
> doesn't seem to be sufficient, since Gnus keeps changing the window
> layout to its Summary/Article split, and the only way I've found to deal
> with that is to keep programs whose layout I care about in separate
> frames.)
> 
> Anyway, it's redundant to have to manually put ERC in its own frame
> every time I launch it.
> 
> I have somethink like this bound to a key:
> 
>   (erc :server "localhost")
> 
> Some programs have the ability to launch in a new frame built into them,
> but shouldn't you be able to do that with almost any program?  If I
> wanted to run the above in an 80x24 frame at a particular X coordinate,
> how would I say that in Elisp?
> 

To add to my other response

    M-x customize-group erc

gives me hints on where I should be looking.

    Show Value Erc Join Buffer
       Determines how to display a newly created IRC buffer. More

    Show Value Erc Reuse Buffers
       If nil, create new buffers on joining a channel/query. More

Just those two custom variables is probably what you need.

RE: launch a program in an arbitrary frame

[Drew Adams]

> I often run ERC to connect to IM services via a local Bitlbee daemon.
> It works best running in its own frame, so I know when people are
> talking to me without having to flip through all my buffers.  (A window
> doesn't seem to be sufficient, since Gnus keeps changing the window
> layout to its Summary/Article split, and the only way I've found to deal
> with that is to keep programs whose layout I care about in separate
> frames.)
> 
> Anyway, it's redundant to have to manually put ERC in its own frame
> every time I launch it.
> 
> I have somethink like this bound to a key:
> 
>   (erc :server "localhost")
> 
> Some programs have the ability to launch in a new frame built into them,
> but shouldn't you be able to do that with almost any program?  If I
> wanted to run the above in an 80x24 frame at a particular X coordinate,
> how would I say that in Elisp?

Here is one possibility perhaps (I don't use ERC).

Find out what the name of the buffer is that you want to have its own
frame.  Then just customize option `special-display-buffer-names' to
include that name.

(If there are multiple such buffers then either add each of their
names to that option value or, if the buffer names follow a simple
pattern, add a regexp that matches those names to the value of option
`special-display-regexps'.)

`C-h v' will tell you info about these user options.  It will also
tell you that Emacs considers them to be deprecated in favor of
(hyper-complex) option `display-buffer-alist'.  If you prefer to
wrestle with that option then go ahead.

To me, `special-display-buffer-names' is super simple, and it does
just what it says it does.  And of course "deprecated" does not
mean "unsupported" - it still works fine, thank goodness.  Anyway,
it's your choice.  If you need help with `display-buffer-alist',
hopefully someone else will have some advice.  My 2 cents is bet
on `special-display-buffer-names'.

By default, a "special-display" buffer is shown in its own frame.
Specifically, as `C-h v special-display-buffer-names' tells you, it:

 "displays the buffer in a way specified by `special-display-function'.
 `special-display-popup-frame' (the default for `special-display-function')
 usually displays the buffer in a separate frame made with the parameters
 specified by `special-display-frame-alist'.

So try customizing option `special-display-buffer-names'.  You can
also customize `special-display-frame-alist', if you want the frame
to have certain properties (e.g. different background color or whatever).

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

> I often run ERC to connect to IM services via
> a local Bitlbee daemon. It works best running in its
> own frame, so I know when people are talking to me
> without having to flip through all my buffers. (A
> window doesn't seem to be sufficient, since Gnus
> keeps changing the window layout to its
> Summary/Article split, and the only way I've found
> to deal with that is to keep programs whose layout
> I care about in separate frames.)

You sure have to hear a lot before the longears fall
of. A Gnus *and* ERC user?! ... *bows*

OK, Gnus is infamous for messing up the windows all
the time. But because you can prevent it, it is all
forgiven. Actually we are happy, that Gnus made us
better programmers. It is just tough love!

If you want to give the window approach another shot,
it may look like this:

(setq display-buffer-alist
      '(("\\*\\(Help\\|Server\\)\\*" display-buffer-same-window)) )

Here two things happen. The help buffers look like
this: *Help*. The Gnus server buffer, like this:
*Server*. The regexp catches them both. Now they
appear in the same window, which is much more natural.
Go to the window where you want something to happen.
Invoke the command. Done and done.

To try if it works, eval the above Elisp, then go to
Gnus' *Group* buffer. Here, hit whatever key you have
for `gnus-group-enter-server-mode' (perhaps ^; I have
it S for server - mnemonic, you see! I'm smart...).

If other buffers behave the same way (e.g., *Group*)
add them the same way.

Good luck! Keep us updated...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

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

> Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:
>
>> I often run ERC to connect to IM services via
>> a local Bitlbee daemon. It works best running in its
>> own frame, so I know when people are talking to me
>> without having to flip through all my buffers. (A
>> window doesn't seem to be sufficient, since Gnus
>> keeps changing the window layout to its
>> Summary/Article split, and the only way I've found
>> to deal with that is to keep programs whose layout
>> I care about in separate frames.)
>
> You sure have to hear a lot before the longears fall
> of. A Gnus *and* ERC user?! ... *bows*

The whole reason I got into Emacs was because I was hoping it could
bring my Internet usage back to the happy days back when it was almost
all text, almost all done through the keyboard, all in one integrated
environment (no more "mousercize" to use the Internet).  The mouse slows
me down and makes me keep having to move my right arm back and forth.

And on any kind of Unix system, adjusting any setting is usually done
with text files in a text editor.  Emacs just seemed like it could bring
it all together, system administration and Internet usage, and make the
mouse only necessary for programs that truly need to be graphical.  I'm
gradually realizing that, and it's a really elegant way of working.

The AJAX sites like Facebook still need a thick browser like Firefox.  I
ran into a message thread in another forum where people were talking
about integrating full WebKit suite capabilities into an Emacs browser,
but Stallman was against it.

To which, I say...GOOD!!!  I'm glad the voice of reason (ok, the voice
of RMS) is prevailing here!  The last thing Emacs needs is for the
twenty ton bloat that now affects thick web browsers to come like a
snake into paradise and afflict us all.  Sure, it might be tempting to
access a few of these types of sites within Emacs...but I am so glad RMS
is not going to let us pay a price like that for it.

Anyway, Emacs is basically turning into the console through which I use
the Internet and do all things on my system (and other systems).

> OK, Gnus is infamous for messing up the windows all
> the time. But because you can prevent it, it is all
> forgiven. Actually we are happy, that Gnus made us
> better programmers. It is just tough love!
>
> If you want to give the window approach another shot,
> it may look like this:
>
> (setq display-buffer-alist
>       '(("\\*\\(Help\\|Server\\)\\*" display-buffer-same-window)) )
>
> Here two things happen. The help buffers look like
> this: *Help*. The Gnus server buffer, like this:
> *Server*. The regexp catches them both. Now they
> appear in the same window, which is much more natural.
> Go to the window where you want something to happen.
> Invoke the command. Done and done.
>
> To try if it works, eval the above Elisp, then go to
> Gnus' *Group* buffer. Here, hit whatever key you have
> for `gnus-group-enter-server-mode' (perhaps ^; I have
> it S for server - mnemonic, you see! I'm smart...).
>
> If other buffers behave the same way (e.g., *Group*)
> add them the same way.
>
> Good luck! Keep us updated...

Well, that isn't the way Gnus is messing my windows up.  It's more like
this:

Say you have three buffers setup with a window layout you like.  You
launch Gnus.  It brings up its Group buffer, and so far, you're fine.
Then you read an article, and the whole frame is replaced with Gnus'
Group/Article split -- so much for your window layout.  It's the
Group/Article split that seems to make Gnus incompatible with any kind
of window layout you might be using, so I've just been putting anything
that I care about the layout of in a separate frame.  The Gnus Help and
Server buffers haven't been doing anything bad to me -- they're just
simple single-window screens.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Eli Zaretskii]

> From: Hikaru Ichijyo <ichijyo@macross.sdf.jp>
> Date: Sat, 18 Jul 2015 10:53:19 -0500
> 
> I ran into a message thread in another forum where people were
> talking about integrating full WebKit suite capabilities into an
> Emacs browser, but Stallman was against it.
> 
> To which, I say...GOOD!!!  I'm glad the voice of reason (ok, the voice
> of RMS) is prevailing here!

I don't recollect such a discussion, nor RMS's opposition, but WebKit
widgets are already possible in Emacs (in the development sources),
albeit only on GTK platforms and if Emacs was built with that support
enabled.

> The last thing Emacs needs is for the twenty ton bloat that now
> affects thick web browsers to come like a snake into paradise and
> afflict us all.

Emacs is very large, but other packages get bloated so much faster
that Emacs's large size is rather small by today's standards.

Re: launch a program in an arbitrary frame

[Óscar Fuentes]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

> The whole reason I got into Emacs was because I was hoping it could
> bring my Internet usage back to the happy days back when it was almost
> all text, almost all done through the keyboard, all in one integrated
> environment (no more "mousercize" to use the Internet).  The mouse slows
> me down and makes me keep having to move my right arm back and forth.
>
> And on any kind of Unix system, adjusting any setting is usually done
> with text files in a text editor.  Emacs just seemed like it could bring
> it all together, system administration and Internet usage, and make the
> mouse only necessary for programs that truly need to be graphical.  I'm
> gradually realizing that, and it's a really elegant way of working.

You have Conkeror ( http://conkeror.org/ ) and Vimperator (
http://www.vimperator.org/ ) Both are keyboard-driven and configuration
is done with plain text files.

Personally I prefer Vimperator when a full-featured browser is
unavoidable, otherwise I use eww (the integrated Emacs web browser.)

[snip]

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

Eli Zaretskii <eliz@gnu.org> writes:

> Emacs is very large, but other packages get bloated so much faster
> that Emacs's large size is rather small by today's standards.

Yes, I remember Eight Megs Always Continually Swapping...  :)

But you're right -- by today's standards, it's a very thin application.
On my system, it launches in about one second, even with all the stuff
I've got in my ~/.emacs.  Everything is nearly instant, and if anything
ever causes system-wide problems, you can be sure it's never Emacs.

It's gone from being regarded as a monstrosity to a model citizen
desktop application, all just because everything else got go bloated in
comparison.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

> But you're right -- by today's standards, it's
> a very thin application. On my system, it launches
> in about one second, even with all the stuff I've
> got in my ~/.emacs. Everything is nearly instant,
> and if anything ever causes system-wide problems,
> you can be sure it's never Emacs.
>
> It's gone from being regarded as a monstrosity to
> a model citizen desktop application, all just
> because everything else got go bloated
> in comparison.

This is all confusing! It is better to not use words
like "thin", "bloated" etc. What does it mean?

My Emacs binary, /usr/bin/emacs24-nox, is
13625528 bytes, or ~13M. The emacs24 package in the
Debian repos is, uncompressed, 17.8 M. The software
itself is very powerful and feature-rich.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

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

> Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:
>
>> But you're right -- by today's standards, it's
>> a very thin application. On my system, it launches
>> in about one second, even with all the stuff I've
>> got in my ~/.emacs. Everything is nearly instant,
>> and if anything ever causes system-wide problems,
>> you can be sure it's never Emacs.
>>
>> It's gone from being regarded as a monstrosity to
>> a model citizen desktop application, all just
>> because everything else got go bloated
>> in comparison.
>
> This is all confusing! It is better to not use words
> like "thin", "bloated" etc. What does it mean?
>
> My Emacs binary, /usr/bin/emacs24-nox, is
> 13625528 bytes, or ~13M. The emacs24 package in the
> Debian repos is, uncompressed, 17.8 M. The software
> itself is very powerful and feature-rich.

Generally, I just meant that I remember in the 1980's and 90's, people
used to joke about Emacs being enormous.  On 80's workstations, it might
take all the memory in your machine just to run an Emacs session.  Now I
can't think of many programs that are friendlier to your resources.
Emacs didn't change though -- the standards of "normal" did.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

RE: launch a program in an arbitrary frame

[Drew Adams]

> Generally, I just meant that I remember in the 1980's and 90's, people
> used to joke about Emacs being enormous.  On 80's workstations, it might
> take all the memory in your machine just to run an Emacs session.

Do you remember Emacs being a memory hog back then, or do you just
remember hearing someone joke about it that way?

FWIW, I used Emacs heavily back then, on Unix workstations, Lisp
machines, and terminals (UNIX, VAX/VMS).  I never found it to be
a memory hog or sluggish or bloated.  Clearly, Emacs was smaller
back then too, but I've never noticed it being particularly slow.

Certainly, no one I knew ever had the impression that it "might
take all the memory in your machine just to run an Emacs session."
My recollection tells me that's a wild fairy tale.  Early PCs were
limited (and didn't run Emacs), but not workstations.

I even used Emacs sometimes on a very limited baud stream over a
phone line, where you often had to fiddle with `C-l' (to refresh,
slowly, top to bottom - like watching a Surveyor image arrive from
an early moon landing) and scroll locking.  In that context, yes,
the slow response could be a pain, but that was the wire, not Emacs
- anything "interactive" over such a wire was slow.

Of course, for someone used to `vi' and starting up the editor
each time even to change only a few chars, Emacs was, and is,
slow to start and use, by comparison.  But such comparisons have
always been essentially apples-to-oranges.

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

Drew Adams <drew.adams@oracle.com> writes:

> FWIW, I used Emacs heavily back then, on Unix workstations, Lisp
> machines, and terminals (UNIX, VAX/VMS).  I never found it to be
> a memory hog or sluggish or bloated.  Clearly, Emacs was smaller
> back then too, but I've never noticed it being particularly slow.

Remember, there was a time it was considered impressive to PC users to
have memory measured in megabytes...any number of megabytes.  Even one
megabyte could be seen as a lot.

80's workstations would have several meg...but is that really a lot if
you're going to run a serious Emacs session with lots of buffers?  Keep
in mind, the whole point of Emacs is to keep it running and accumulate
as much of what you work with on disk as possible, in memory.  That
concept was a little ahead of its time, or at least, ahead of the
hardware that was running it.  Since it sounds like you were on UNIX
machines that early, you may also remember that when X came around, some
people considered that a luxury, since that took a lot of system memory
too, even on machines that had a framebuffer and were made for it.  A
lot of people just prefered to do without it.

Not only was Emacs considered a hog by some people at that time, but
later in the early 90's, some people even felt that way about the
then-new bash shell.  After all, it took about a meg of memory.  On some
of the early machines, that was a pretty big chunk of all the memory you
had, just for a shell.  Even Chet Ramey was a bit embarrassed about it,
though I doubt anyone really cares about how much memory we use per
invocation of bash now.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

> the whole point of Emacs is to keep it running and
> accumulate as much of what you work with on disk as
> possible, in memory.

Is *that* the whole point of Emacs?

It is amazing. You learn something new every day.
Except for Thursdays, because then I eat
split pea soup!

:)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

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

> Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:
>
>> the whole point of Emacs is to keep it running and
>> accumulate as much of what you work with on disk as
>> possible, in memory.
>
> Is *that* the whole point of Emacs?

Well, I suppose I should say that everything I've read from anyone about
it so far has led me in that direction, and from observing the way Emacs
works, I get the impression they're right.  I don't have a citation
handy, but if I had a nickel for every time I've heard someone say that
constantly quitting and relaunching Emacs gets rid of valuable
accumulated information from your session; that people who launch Emacs
as a sub-process to use it as a text editor and then kill it are missing
the point; that some people apparently feel so strongly about it that
emacsclient was created (and before that, gnuclient), just to make sure
you'd never have to spawn Emacs as a disposable process for
anything...etc, etc.  The whole thing seems setup from the ground up to
accumulate buffers.  The command to kill the buffer you're currently
looking at (kill-this-buffer) doesn't even have a key binding unless you
give it one yourself.

From all of this, yes, I've definitely gotten the impression over the
years that once you decide something is important enough load from disk,
Emacs decides it's important enough to hang onto in case you want it
again, and you have to be very deliberate about making it not do that.
It does seem to be Emacs' whole paradigm -- caching your work for later.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

RE: launch a program in an arbitrary frame

[Drew Adams]

> > FWIW, I used Emacs heavily back then, on Unix workstations, Lisp
> > machines, and terminals (UNIX, VAX/VMS).  I never found it to be
> > a memory hog or sluggish or bloated.  Clearly, Emacs was smaller
> > back then too, but I've never noticed it being particularly slow.
> 
> Remember, there was a time it was considered impressive to PC users to
> have memory measured in megabytes...any number of megabytes.  Even one
> megabyte could be seen as a lot.
> 80's workstations would have several meg...but is that really a lot if
> you're going to run a serious Emacs session with lots of buffers?

Whatever they had was more than enough for running Emacs, in my
experience.  Whether Sun, SGI, or another brand.  Other applications
could sometimes tax a workstation, but not Emacs.  (Of course, you
could use Emacs, or any other program, to do heavy enough work to
bring any system to a crawl.)

> Keep in mind, the whole point of Emacs is...

It wasn't a problem.  At all.  Do you remember it being a problem
to use Emacs on a workstation, or are you just repeating something
you heard?  So far, you've said that workstations were limited in
resources and Emacs was/is a memory hog.  Do you actually remember
having a problem using Emacs on a workstation in the 80s?  It would
be interesting to hear from others too about this.

> Since it sounds like you were on UNIX machines that early, you
> may also remember that when X came around, some people considered
> that a luxury, since that took a lot of system memory too, even
> on machines that had a framebuffer and were made for it.  A
> lot of people just prefered to do without it.

For the most part, we did use X when it came out.  Yes, it was
a monster, but many people found it worth it.  The question here
is about Emacs, however.  Emacs is not X Window - far from it.

> Not only was Emacs considered a hog by some people at that time,
> but later in the early 90's

That's not my recollection.  Except by comparison with editors
like `vi'.  I don't recall Emacs ever slowing anyone down.

Remember, you could (and still can) use Emacs in terminal mode,
which alone can make a big difference if your context is limited.
But when graphic Emacs became available I used it most of the
time, and I do not recall any performance problems with it.

> some people even felt that way about the then-new bash shell.

X Window and bash are not Emacs.

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Drew Adams <drew.adams@oracle.com> writes:

> Whatever they had was more than enough for running
> Emacs, in my experience. Whether Sun, SGI, or
> another brand. Other applications could sometimes
> tax a workstation, but not Emacs.

SGI = Silicon Graphics International?

"Silicon Graphics International, formerly Rackable
Systems, which acquired the former Silicon Graphics,
Inc"
(https://en.wikipedia.org/wiki/Silicon_Graphics_International)

> It wasn't a problem. At all. Do you remember it
> being a problem to use Emacs on a workstation, or
> are you just repeating something you heard? So far,
> you've said that workstations were limited in
> resources and Emacs was/is a memory hog. Do you
> actually remember having a problem using Emacs on
> a workstation in the 80s? It would be interesting to
> hear from others too about this.

It would be (even more) interesting if you told us
more about those days and spent less an effort trying
to bust the OP :)

>> some people even felt that way about the then-new
>> bash shell.
>
> X Window and bash are not Emacs.

I can definitely see X being slow then as well as
today, with graphics always being slow save for spoilt
kids who run monster machines bought by their affluent
but absent parents, only so the kids can play moronic
FPSs and share porn... and besides (with X), that
interesting but complicated distributed architecture
won't win any horse races, I reckon. But bash?! For
a shell to be slow, and to slow down the entire
system, something has to be seriously wrong. Anyway,
if there isn't a shell, and no GUI or base window
system, how do you interact with the system? Or do you
mean people who thought bash was too slow still had
the hardware to run a predecessor shell - simply the
Bourne shell, or perhaps [a]sh?

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: launch a program in an arbitrary frame

[Drew Adams]

> > Whatever they had was more than enough for running
> > Emacs, in my experience. Whether Sun, SGI, or
> > another brand. Other applications could sometimes
> > tax a workstation, but not Emacs.
> 
> SGI = Silicon Graphics International?
> (https://en.wikipedia.org/wiki/Silicon_Graphics_International)

More precisely:
https://en.wikipedia.org/wiki/Silicon_Graphics

Re: launch a program in an arbitrary frame

[Pascal J. Bourguignon]

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

>>> some people even felt that way about the then-new
>>> bash shell.
>>
>> X Window and bash are not Emacs.
>
> I can definitely see X being slow then as well as
> today, with graphics always being slow save for spoilt
> kids who run monster machines bought by their affluent
> but absent parents, only so the kids can play moronic
> FPSs and share porn... and besides (with X), that
> interesting but complicated distributed architecture
> won't win any horse races, I reckon. But bash?! For
> a shell to be slow, and to slow down the entire
> system, something has to be seriously wrong. Anyway,
> if there isn't a shell, and no GUI or base window
> system, how do you interact with the system? Or do you
> mean people who thought bash was too slow still had
> the hardware to run a predecessor shell - simply the
> Bourne shell, or perhaps [a]sh?

https://web.stanford.edu/~ouster/cgi-bin/papers/osfaster.pdf

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

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

> You have Conkeror ( http://conkeror.org/ ) and Vimperator (
> http://www.vimperator.org/ ) Both are keyboard-driven and configuration
> is done with plain text files.
>
> Personally I prefer Vimperator when a full-featured browser is
> unavoidable, otherwise I use eww (the integrated Emacs web browser.)

The thing I like about Emacs is it's not just a web solution.  It also
gives me mail and news, IRC, IM, a client for browsing local and remote
disks (through almost any protocol), revision control using any backend
I want, compiler/debugger integration, and it's all controlled with the
same keystrokes uniformly across all these programs.  I don't just want
a GUI web browser that has keyboard shortcuts -- I want to bring all my
machine usage under one organized lion-tamer.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

> The whole reason I got into Emacs was because I was
> hoping it could bring my Internet usage back to the
> happy days back when it was almost all text, almost
> all done through the keyboard, all in one integrated
> environment (no more "mousercize" to use the
> Internet). The mouse slows me down and makes me keep
> having to move my right arm back and forth.

100% correct.

> And on any kind of Unix system, adjusting any
> setting is usually done with text files in a text
> editor. Emacs just seemed like it could bring it all
> together, system administration and Internet usage,
> and make the mouse only necessary for programs that
> truly need to be graphical. I'm gradually realizing
> that, and it's a really elegant way of working.

Yes :)

> The AJAX sites like Facebook still need a thick
> browser like Firefox. I ran into a message thread in
> another forum where people were talking about
> integrating full WebKit suite capabilities into an
> Emacs browser, but Stallman was against it.
>
> To which, I say...GOOD!!! I'm glad the voice of
> reason (ok, the voice of RMS) is prevailing here!
> The last thing Emacs needs is for the twenty ton
> bloat that now affects thick web browsers to come
> like a snake into paradise and afflict us all.

1) Of course, I don't like Ajax and absolutely not
   Facebook, however adding support for things one
   doesn't like will have the effect of not alienating
   people who do like those things. If we go the extra
   mile they (perhaps) won't be instantly turned
   off/afraid, and in time and gradually they will be
   exposed to different things through the back door,
   and in even more time perhaps that will make them
   drop the Facebook etc. hysteria and become
   independent computer users.

2) This "bloat" thing is often based on
   a misconception that stems from the Windoze and
   accursed Apple systems which have desktops that are
   relentless in bugging you and driving you crazy
   with popups, icons - all kinds of visual noise.
   To be honest, the thrice-accursed Linux world has
   not been immune to this and many popular distros
   have walked the same sad path.

   The reaction to this has been the wish for
   a "minimal", "streamlined", and "clean" system.
   But just because you have tons of features,
   software, and power, that doesn't mean your system
   has to be bulky, ill-organized or "dirty"! There is
   no such correlation. It can be, if the GUI is such
   that for every piece of software you install, you
   get another annoying icon, popup, menu, etc.
   But that is the *GUI* in particular, and not the
   software toolkit or the system. What you see, don't
   have to be what (all) you get! Didn't you watch the
   "Robots in disguise" show as a kid?

   Here is an example:

       http://user.it.uu.se/~embe8573/dumps/system.png

   'lspath' is a zsh function:

        lspath () {
          (($#)) || set ''
          print -lr -- $^path/*$^@*(N:t) | sort -u
        }

    What it does is, it lists all the executables in
    the user's PATH ("path" is a zsh feature). As you
    see from the screenshot, that number is 3356! And,
    if that number is 10 000 or even 100 000, assuming
    the software is good, the screenshot will look
    just the same, save for the change of that digit.
    Adding more things doesn't have to add the
    "bloat" unless you let it!

    So it is not "bloated" just because it has
    features, tools, and power, it is (can be) bloated
    because the GUI chooses to put all this in your
    face *all the time*, instead of when you yourself
    say it is time to use a particular piece of
    software, at what time that, and only that, is
    invoked and displayed.

> Anyway, Emacs is basically turning into the console
> through which I use the Internet and do all things
> on my system (and other systems).

Yes. Before there was a desktop, there was an editor.
The editor was much more powerful, but people couldn't
handle all that power. Now, many people that would
instinctively use the editor simply do not know there
is an alternative to the desktop. It is a sad state.
All we can do is do the right thing ourselves.

    I'm not trying to preach. I believe I can reach.
    But your mind ain't prepared. I see you when you
    get there. (Coolio 1997)

> Well, that isn't the way Gnus is messing my
> windows up.
>
> It's more like this:
>
> Say you have three buffers setup with a window
> layout you like. You launch Gnus. It brings up its
> Group buffer, and so far, you're fine. Then you read
> an article, and the whole frame is replaced with
> Gnus' Group/Article split -- so much for your window
> layout. It's the Group/Article split that seems to
> make Gnus incompatible with any kind of window
> layout you might be using, so I've just been putting
> anything that I care about the layout of in
> a separate frame. The Gnus Help and Server buffers
> haven't been doing anything bad to me -- they're
> just simple single-window screens.

To me it sounds like it is the same problem and
because of that applying the same solution with
different data is a good first step.

But, to be exact, you display articles from the
summary buffer. Say you have a list of articles.
You hit RET. What do you want to happen then, exactly?
And what do you want not happening, that is?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

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

> Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:
>
>> The AJAX sites like Facebook still need a thick
>> browser like Firefox. I ran into a message thread in
>> another forum where people were talking about
>> integrating full WebKit suite capabilities into an
>> Emacs browser, but Stallman was against it.
>>
>> To which, I say...GOOD!!! I'm glad the voice of
>> reason (ok, the voice of RMS) is prevailing here!
>> The last thing Emacs needs is for the twenty ton
>> bloat that now affects thick web browsers to come
>> like a snake into paradise and afflict us all.
>
> 1) Of course, I don't like Ajax and absolutely not
>    Facebook, however adding support for things one
>    doesn't like will have the effect of not alienating
>    people who do like those things. If we go the extra
>    mile they (perhaps) won't be instantly turned
>    off/afraid, and in time and gradually they will be
>    exposed to different things through the back door,
>    and in even more time perhaps that will make them
>    drop the Facebook etc. hysteria and become
>    independent computer users.
[...]

Well, it'd be nice to be able to display AJAX pages in some way...but I
don't think linking against the same twenty-ton WebKit suite or Mozilla
libraries that the big browsers are using is the way to do it.  In doing
that, we get their memory footprint, and their security problems.

If we could have something clean, secure, and light that'd be great.  I
mostly just want to be able to see the textual information, plus a few
embedded pictures -- kind of like Emacs-W3C.  It'd be nice if it could
be accomplished without twenty meg of tarballed code, written in some
language with buffer overflow problems like C++.

>> Say you have three buffers setup with a window
>> layout you like. You launch Gnus. It brings up its
>> Group buffer, and so far, you're fine. Then you read
>> an article, and the whole frame is replaced with
>> Gnus' Group/Article split -- so much for your window
>> layout. It's the Group/Article split that seems to
>> make Gnus incompatible with any kind of window
>> layout you might be using, so I've just been putting
>> anything that I care about the layout of in
>> a separate frame. The Gnus Help and Server buffers
>> haven't been doing anything bad to me -- they're
>> just simple single-window screens.
>
> To me it sounds like it is the same problem and
> because of that applying the same solution with
> different data is a good first step.
>
> But, to be exact, you display articles from the
> summary buffer. Say you have a list of articles.
> You hit RET. What do you want to happen then, exactly?
> And what do you want not happening, that is?

It's not what happens when I'm actually using Gnus that's the problem
really.  When I'm looking a Summary buffer list of articles, I hit RET
on one, and it splits the frame into roughly 1/5th / 4/5ths, and
displays the article in the bottom part.  That's great.

But now let's say I'm done using Gnus, and I want to go back to the
three buffers I had all laid out the way I wanted before I ran Gnus.  My
window layout is gone.  I can bring up the buffers again, but I'd have
to recreate the splits.

I tried using Winner mode, but it seems it doesn't know how to recall
the window layout either (even though this sort of thing is supposed to
be what Winner mode is for).  I've just resorted to using frames any
time I have window splits I don't want Gnus to be able to mess with.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

> it'd be nice to be able to display AJAX pages in
> some way... but I don't think linking against the
> same twenty-ton WebKit suite or Mozilla libraries
> that the big browsers are using is the way to do it.
> In doing that, we get their memory footprint, and
> their security problems.

No one is suggesting that.

> If we could have something clean, secure, and light
> that'd be great. I mostly just want to be able to
> see the textual information, plus a few embedded
> pictures -- kind of like Emacs-W3C. It'd be nice if
> it could be accomplished without twenty meg of
> tarballed code, written in some language with buffer
> overflow problems like C++.

Again, I'd recommend not using words such as "clean",
"secure", "light", etc. They don't carry any meaning.
No one is suggesting we have something "dirty",
"insecure", or "heavy"!

20M of tarballed code is nothing in this day and age.
It doesn't matter. What matters is what the code is,
and what program it compiles into, and what that
program does. If the program is brilliant and does
something new (or something old in a better way) it
might as well be 100M for all I care (and you
shouldn't, either).

The language issue is equally irrelevant (in all but
the extreme cases). Emacs is in C and Lisp, which I prefer
to C++ (unless the problem lends itself to
OO/modeling, in which case I prefer C++ to C).
Nonetheless, the expert C++ programmer with
a creative/resourceful mind can do wonders with 20M.
It is not the language, or the size of the tarball,
that matters!

> It's not what happens when I'm actually using Gnus
> that's the problem really. When I'm looking
> a Summary buffer list of articles, I hit RET on one,
> and it splits the frame into roughly 1/5th / 4/5ths,
> and displays the article in the bottom part.
> That's great.
>
> But now let's say I'm done using Gnus, and I want to
> go back to the three buffers I had all laid out the
> way I wanted before I ran Gnus. My window layout is
> gone. I can bring up the buffers again, but I'd have
> to recreate the splits.

OK! This I once knew how to do. What you want is to
push the window configuration to a register each time
you open an article, and then have it restored with
a global keystroke. Hang on, I'll find it...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: launch a program in an arbitrary frame

[Emanuel Berg]

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

> OK! This I once knew how to do. What you want is to
> push the window configuration to a register each
> time you open an article, and then have it restored
> with a global keystroke. Hang on, I'll find it...

Here is how you do it.

With this, save the window configuration with `C-x m',
and store it with `C-x l'. When you show an article
from the *Summary* buffer, it'll save automatically so
you just have to restore it when you are done reading
articles. Unless you load it, it doesn't save again.

(defvar *do-save-new* t)

(defun save-win-conf ()
  (interactive)
  (when *do-save-new*
    (window-configuration-to-register ?0) ))

(defun load-win-conf ()
  (interactive)
  (setq *do-save-new* t)
  (jump-to-register ?0) )

(global-set-key "\C-xm" 'save-win-conf)
(global-set-key "\C-xl" 'load-win-conf)

(defun gnus-summary-show-article-save-win-conf ()
  (interactive)
  (save-win-conf)
  (setq *do-save-new* nil)
  (call-interactively 'gnus-summary-show-article) )

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

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

> Here is how you do it.
>
> With this, save the window configuration with `C-x m',
> and store it with `C-x l'. When you show an article
> from the *Summary* buffer, it'll save automatically so
> you just have to restore it when you are done reading
> articles. Unless you load it, it doesn't save again.
>
> (defvar *do-save-new* t)
>
> (defun save-win-conf ()
>   (interactive)
>   (when *do-save-new*
>     (window-configuration-to-register ?0) ))
>
> (defun load-win-conf ()
>   (interactive)
>   (setq *do-save-new* t)
>   (jump-to-register ?0) )
>
> (global-set-key "\C-xm" 'save-win-conf)
> (global-set-key "\C-xl" 'load-win-conf)
>
> (defun gnus-summary-show-article-save-win-conf ()
>   (interactive)
>   (save-win-conf)
>   (setq *do-save-new* nil)
>   (call-interactively 'gnus-summary-show-article) )

Thanks!

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

> Thanks!

... did it work?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

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

> Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:
>
>> Thanks!
>
> ... did it work?

Yes!

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Hikaru Ichijyo]

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

> 20M of tarballed code is nothing in this day and age.
> It doesn't matter. What matters is what the code is,
> and what program it compiles into, and what that
> program does. If the program is brilliant and does
> something new (or something old in a better way) it
> might as well be 100M for all I care (and you
> shouldn't, either).
>
> The language issue is equally irrelevant (in all but
> the extreme cases). Emacs is in C and Lisp, which I prefer
> to C++ (unless the problem lends itself to
> OO/modeling, in which case I prefer C++ to C).
> Nonetheless, the expert C++ programmer with
> a creative/resourceful mind can do wonders with 20M.
> It is not the language, or the size of the tarball,
> that matters!

Well, for security, the size of it sort of does matter.  When we start
talking about web browsers, we're talking about code in a hostile
environment.  The big browsers have gotten themselves into a situation
where they are now so big that no one could possibly audit them.  I
don't want a browser like that to be a bundled part of Emacs.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: launch a program in an arbitrary frame

[Emanuel Berg]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

> Well, for security, the size of it sort of does
> matter. When we start talking about web browsers,
> we're talking about code in a hostile environment.
> The big browsers have gotten themselves into
> a situation where they are now so big that no one
> could possibly audit them. I don't want a browser
> like that to be a bundled part of Emacs.

Size doesn't matter. It is an illusion. Only speed,
power, and skills matter. And dedication,
resourcefulness, creativity, activity, etc. etc.

Did you ever hear about

    https://en.wikipedia.org/wiki/Manny_Pacquiao

and

    https://en.wikipedia.org/wiki/Odysseus

?

-- 
underground experts united
http://user.it.uu.se/~embe8573