Thanks, Howard, for the great talk.
We have the Q&A now open.
Folks are welcome to put their questions on the pad on IRC, and we might also open up
this room in a few minutes if you might prefer to join Big Blue Button directly and ask your
questions to Howard that way.
Yeah, so Howard, take it away.
Thank you, thank you.
Yeah, I wasn't expecting to have a Q&A.
Tried to condense it so fast because this was supposed to be a lightning talk, but hey,
it's good to talk to everybody.
So question on the Etherpad here is, do I fall back to vterm only when needing terminal
emulation?
And yeah, I kind of know when I'm going to need that based on the use case.
Like right now, I'm doing a lot of building with Docker, and Docker just makes a mess
out of everything.
And so I can sometimes will like start up a vterm for that.
But I don't like actually typing a lot of stuff in there as much.
So actually, I wrote a little program to, you know, the compile command, I just send
the compile over into it that I could see the output and then I could just and it pops
right back to where I'm at.
So I don't know, I think you kind of need to use a little bit of both.
But yeah, it would be nice to kind of flip a window back and forth because there's some
things about Eshell that I actually do like a lot.
Now my Tramp suggestion, okay, I'll admit Tramp is, it's kind of fickle.
I think we all get sometimes better use cases out of it than others.
Uh oh, my headphones are out of batteries here.
So we might have to flip here.
But yeah, so the Tramp, I don't know.
I think we have to kind of play with it and see how it goes.
See another question is, have we thought about adding the Eshell manual?
You know, after doing this talk and I'm realizing a lot of the half baked or almost good stuff
with Eshell that we could just kind of fix a little bit and some of the, especially some
of the docs, yeah, I'm kind of thinking that maybe, maybe I should hook up with somebody
and we could try to do a little bit of extensions there, you know, like fix up the manual a
little bit more, make it more of a tutorial, I think would help as well as fixing some
of the little problems like that.
Trying to be able to cat a buffer into the shell, I think is pretty useful.
Let's see, do I know if Eshell can be used from Elisp?
Yeah, I use that quite a bit.
I actually have functions that call an Eshell command.
That way I get all of the, you know, the benefits that you can get from an Eshell, like with
the predicates and all that kind of thing.
I can't remember who's been doing it, but lately I've been seeing a lot of the do what
I mean shell commands that they're, they're building up a bunch of functions that do very
specific things, what they need.
And it seems like there's a lot of like special commands they're adding into it to like get
the file name and that sort of thing.
And I was thinking, Hey, that's a great idea, but let's do it with Eshell.
So I've been doing something similar, but just calling out to Eshell itself.
Let's see, next question, how does that interplay with my literate dellop bop approach?
Yeah, the two are different.
You know, when I'm doing my literate work, you know, I'm in an org file and I'm just
writing commands, but yeah, sometimes it's just a little bit, you know, I'm not planning
on keeping it.
I'm just kind of investigating things and that's what rebels are really good for.
And in that case, yeah, I'll pop over into Eshell, write things.
If I see something good, that's where I was talking about my little engineering notebook,
sending it out to a capture and then, and capturing it out or writing it into a buffer
where I can do more things to it.
I guess it's the flexibility I think we all kind of need because you don't know exactly
where you're going until you're halfway there.
And it's like, Oh, I don't want to start up a new app.
That's why we're an Emacs.
So yeah.
Oh yeah.
Thank you.
Yeah.
Alvaro Ramineers.
Yeah.
That's the stuff I've been reading a lot about.
Let's see.
Another question.
Do I have a strategy for getting around Eshell's lack of support for input redirection?
You know, it is what it is.
I don't have any ideas at the moment.
It's a good idea.
Whenever, you know, we're so used to doing pipes and whenever you start doing a pipe
at all, Eshell just immediately throws it into the shell.
But then pulling it back in is kind of difficult.
So that's why I just started writing them out to buffers and then pulling them back
in.
And I find that just a little bit more useful situation for what I'm doing.
I don't know if other people will find it as useful as I do.
But yeah, I'm getting a little tired of trying to get just the right command of piping everything
together.
And two years ago when I was talking about my little piper idea, this is kind of what
it's morphed into was just using Eshell, running the commands, editing the stuff and then pulling
it back in to send it to some other app.
Or not even pulling it back in, just using it at that point and sending it off into emails.
Yes, you can call elist functions, the commands.
I was hoping this could be kind of clarified a little bit.
But if you have any function, any emacs list function that starts with Eshell slash, that
gets called first before any command.
So you can override just about every shell command.
That many of them are.
So there is an Eshell slash ls.
So if you type ls into your Eshell, it's actually calling that function.
Now most of those functions will, if it runs into too many options that it doesn't know
about or something like that, call out to whatever ls program you've got installed.
But that's how it goes.
So yes, buffers are superior pipes.
Whoever is typing that, I think that's a great idea.
I think that's kind of the concept that I'm realizing this year.
Hold on one second while I switch headphones here.
I suppose you can still hear me, right?
Yep, I can still hear you.
Well, nobody's talking yet.
I can still hear you.
OK, perfect, perfect.
And I can hear you too.
So that works well.
Let's see.
Any other questions in the IRC?
Not seeing them mostly in the etherpad here.
Do I have a preferred method for getting argument completion for shell commands?
OK, that's a really good question.
There is a function that I found in Eshell for getting options.
And it's like, great, that's what I was expecting, something like a get ops.
So I start playing around with it, and it's like almost there.
The problem is it's not really as flexible as I would think.
It either takes command line arguments or it doesn't.
And it's kind of made for very simple commands only.
So well, I ended up writing my own.
So I wrote kind of a get ops like function, kind of behaves like it, where you can give
it a list of single commands, a list of those long commands, some that take options and
some that don't.
And you'll see that in my, where I've got it here in the etherpad up on the full code.
I also posted it up on Mastodon as well earlier.
But I have a link to my configuration file.
It's all literate.
So you can just scroll down, search for get ops, and you'll see my function.
I haven't fully tested out everything yet.
Most of the code was actually written for this talk, I found.
And so there will be bugs.
But you know, you might find it interesting to grab some of the stuff and play around
with it.
If you find some bugs, please send them back to me.
I'll discover them soon enough.
So is it possible to get L.base completion for elist calls and eshell?
Good question.
I don't know.
I have been switching from company mode to Corfu.
Just try it all out.
I'm getting some pretty good completions, but the EL doc based would be, that would
be very lovely.
A plan nine smart shell.
Sorry, sorry.
Oh, yes.
I do remember reading Mickey Peterson's article on eshell and his plan nine idea.
I was playing around with it for a little bit, but I don't know.
Yeah.
I couldn't get it quite working the way I thought I would want it to, so I didn't follow
through.
But I just got some good ideas there.
Any other questions?
But yes, I should, yeah, I should revisit Mickey Peterson's ideas.
Say it again.
Cool.
Yeah, sorry.
I guess I was just going to ask a question on the fly here.
Sure.
Yeah, which is, so you mentioned this sort of get up function or get up like function
that you implemented.
Would you consider maybe having that integrated in Emacs core itself so that it's available
to all other eshell users?
I think that'd be a great idea and I'm kind of thinking I need to kind of see what should
go into eshell and what should maybe be like a side package like eshell ext kind of thing
for getting some extra stuff because I don't know if everybody wants all of it.
So having a side package might be a really good idea and then seeing, yeah.
So yes, if you want to work on it with me.
Yeah, sure.
Sounds good.
Why not?
Sure.
All right.
Any other questions or good?
I think we still have about, sorry.
Go ahead.
Oh, I was going to say I think we're out of questions.
Right?
Yeah.
But we still are not out of time yet.
So I think I've got more time for Q&A than I thought I had for the actual talk.
Yeah, it's been interesting.
So we were kind of debating on switching to two tracks like we have done this year or
keeping or maintaining the same setup as the previous years, which was one track.
But sort of all the talks were very like squeezing together and it was a last minute decision
kind of.
And we almost did end up going back to one track.
But we're here.
And I think that's the reason why some of the Q&As are sometimes longer than the talks
themselves.
Well, okay.
So personally, I love the two track idea and I love all the breaks.
It's made it a lot easier because last year it's like, oh, I can't even get up.
Yeah, I feel you.
And I feel the same too.
Both, I mean, as someone who's been a little bit watching, but also as organizers, I mean,
you couldn't catch a breath with like that one track rapid fire of talks one after another.
So this is much better, I feel like.
Yeah.
So let's keep it.
Let's keep it going.
Yeah.
And next year, maybe I can do 15 minutes.
Yes.
Mal?
Yes.
Are you the maintainer of Eshell now?
No, I'm not.
Just an interested bystander.
I think Eshell is still just part of Core.
John Wiggly wrote it originally, but I think it's just part of the core.
So I don't think anyone is maintaining it per se.
It certainly is getting a little long in the tooth and we probably need to do some updatings
on it.
So maybe that's what we should do for version 30.
Yeah, I've started to use it a little bit more just because of all the chatter on the
various blogs, right?
There is a lot of chatter lately.
But it burned me recently for like half an hour because I was trying to SSH into a machine
from Eshell.
And usually, I use just regular shell mode.
And for some reason, it just didn't connect up to the SSH agent or whatever.
So I was thinking that everything's broken and stuff.
I'm like running around trying to do stuff.
Oh, it's just because I'm in Eshell trying to do this.
Yes, yes.
And if I know I'm going to be SSHing into a box, I don't.
I just start up vterm and go.
Then I know it's going to be pretty good.
I've had a lot of good success in that regard with vterm.
However, the problem is it's hard to pull that kind of stuff back.
Like I'll find something interesting and it's like, oh, crap.
Now I have to control C, control T, and then go up and collect it as opposed to shooting
it out over into an org file with a redirection.
That's why I've been kind of playing around with just using Tramp in Eshell as opposed
to SSHing in.
My knowledge may vary.
I thought in the command interpreter, there's some stuff like...
There is.
It's supposed to be the visual commands.
I think there's a list of them, and SSH is one of those.
It's supposed to then start off as a shell mode, detached little process and feed stuff,
but I don't know.
I haven't had as much luck with it, so I haven't really bothered.
I just jump.
If I know I'm going to SSH, I'll just start a vterm and go.
Well, I mean, aside from doing SSH, just using...
I think there are a couple commands for...
There's one for taking the command on the command line and putting it into the kill
ring, and there's another one for flushing the buffer, flushing the last output of your
buffer, and it works in many different shell or repl-type environments inside Emacs, but
it doesn't put it into the kill ring, which was sort of confusing to me, so I'll have
to dive into the Elisp at some point and figure out how to get what I want.
I think that's the problem with this Eshell.
There's a lot of interesting ideas, but there's a lot that's not quite baked yet.
It's a combination of what we expect, because it's not a terminal emulator shell.
It's not like Bash, it's different, but it's got some cool stuff, so there's expectation,
and then there are just bugs and things that haven't been finished.
I can't remember who started...
I've got a link in my configuration file, but somebody was writing on how to get the
output from the last command in shell, shell mode, and I thought, that's a great idea.
I want that in Eshell, and then I found the source code that there's a double dollar sign
that's already there.
Great.
Wait a minute.
It doesn't work all the time?
What the hell?
When I saw that in your talk, I was like, oh, that's one of the things I've been looking
for.
It is, exactly.
Now, I'll admit, the underpinnings are really good.
It didn't take long to actually make that and fix it, and then make it even better.
Like putting in a kill ring, it's like, now that is nice, so that I could just grab it
as an array and go.
That's really good.
So, I think there's a lot of good stuff there.
I think, yeah, let's just make some features.
Let's make an extension, and let's assign the copyright to the BFSS.
Yeah, maybe I'll start looking at Eshell after.
I'm playing around with org-node right now, trying to catch up to some of the forks, but
maybe Eshell is another, the next thing to sort of poke at.
Aren't there so many fun things to do?
It's terrible.
Great, great, great.
I got another question over here in the IRC, do you ever fall back to terminals and shells
outside of Emacs?
Okay, that, all right, confession time, yes, I sometimes use iterm.
So when I, so when I first boot up, I do have to use a terminal before I start up Emacs
because it's got to mount everything.
So I do use iterm, and yeah, sometimes if it happens to be there, I'll type the command
in there instead of running into Emacs.
But I just find running those terminals to be pretty frustrating because most of them,
you have to use a mouse to copy and select stuff.
Yeah and actually I could maybe chime in here and say that yeah, exactly, not only for terminals
but also for IRC clients, I feel like I've tried using a bunch of different ones, yeah,
but it ultimately comes down to I can't just put the cursor up, you know, quickly grab
something, kill it and paste it somewhere else or just use it.
And yeah, that's, I feel like one of the killer features of Emacs or anything that's built
into Emacs.
Mm-hmm.
Agreed.
Lounge679 says, what are the less well oiled parts of Eshell and the edge cases?
Yeah, that's a great phrasing, less well oiled parts.
There's just a little friction and I think we need to figure out how to fix those things
when we encounter them.
Yeah, I should make a list of the things I found and hey, Mal, you give me a list too.
And yeah.
I think one of the problems with Eshell is that it's not based on comment, like shell
and- It isn't.
Yeah, and as a result, the other shells have like a uniform interface and uniform key bindings
for doing things.
And Eshell does things slightly differently, different enough that-
That's right.
Yeah.
Yeah, exactly.
And that's good and bad.
It's doing something totally different.
And if you know that it's just gonna be different and you'll treat it differently, at least that's
how I found.
So that's why I'm jumping between the vterm and Eshell, depending on what I'm trying to
do.
But I'm just finding there's a lot of interesting stuff in Eshell, but it changes how we run
things.
I think it's very similar to, well, I mean, if, okay, I'm not blaming names, but if you're
a VI user, you're starting with a terminal and you're running commands.
And then when you need to edit a file, you edit, you come back, but the shell is kind
of your main focus.
Well, we're all over here in Emacs and we just run commands from Emacs, right?
That's just how we behave.
And using Eshell is this way where don't go all the way, don't try to, but you can kind
of pretend and do different things.
So yeah, so that's why I say it kind of changes our behavior because it's doing things differently.
So you can't look at it as another common.
Wait, so when you say you're using vterm, does that mean you're using, that's a separate
application outside of Emacs or is there a, oh, oh, yeah.
So vterm is, I don't know when it came out, a couple of years ago, I don't know the details
of it, but it's using a module library to do all the heavy lifting.
So it's just a little better comment and I've just found it to be a lot, very reliable and
pretty fast.
So especially when I'm SSHing into another machine in my data centers and especially
building all the Docker and some of the weird terminal stuff that I need to do in those
shell environments using SSH, I just find vterm to be really good for what that does.
Oh, okay.
I see it now.
It's on an alpha.
All right.
Yeah.
It is in the, you're still in Emacs, but the key bindings are pretty good, but you do,
you know, it has two modes, one for selecting text and then one for being a terminal.
Maybe I'll try that out instead of metax-gel.
Yes, I would, if you can.
The problem that I think most people have is building that vterm library.
I haven't had any problems on my work Mac.
So it's been pretty good for me.
Okay.
All right.
That's good to know about too, but that'll keep me from you like adopting Eshell.
Sure.
You know, that's a nice thing about choices.
Yeah.
You'll just find that vterm, I think behaves exactly like you expect a terminal to act.
And so you won't have, you won't have to do much.
I don't have much in the way of customizations.
It's mostly my customizations is just starting a vterm running SSH automatically.
So it's mostly about working with my external hosts.
And if I may quickly jump in here, I think we have about another minute or so of live
Q&A on the stream at which point then the stream will move on, but you folks are welcome
to stay here or like continue the Q&A on the pad or whatever works best.
Just staying in this room.
Yeah.
And continue talking.
Lovely.
Yeah.
As Karthik has said vterm isn't distracting.
It doesn't, you know, it's, it's just exactly what you expect.
So it's not interesting either.
No, I'm just, yeah, and so there's some good comments on the IRC.
So yeah.
Thanks everybody.
It's been fun.
All right.
I'm going to jump off now.
Nice talking to you, Howard.
You too.
All right.
Thank you all.
I think I'll drop off as well.
All right.
Thank you.