Non file buffers and default-directory

Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Hi,

Whenever Emacs creates a non file buffer (for instance with 'M-x man'),
it sets its default-directory from the one of the buffer you are into.
Most of the time, I don't think it matters but for remote buffers.

A remote default-directory could go "disconnected" (e.g. lost of ssh
after moving network, end of credential after a timeout for sudo...)  In
this case, I use 'tramp-cleanup-all-connections' but this will also
close any *Man* buffers with this default-directory.

I don't have an idea or solution for this issue (that might not be one!)
but I'd just like to know how others deal with this.

Thanks,
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Emanuel Berg]

Manuel Giraud via Users list for the GNU Emacs text editor wrote:

> Whenever Emacs creates a non file buffer (for instance with
> 'M-x man'), it sets its default-directory from the one of
> the buffer you are into. Most of the time, I don't think it
> matters but for remote buffers.
>
> A remote default-directory could go "disconnected" (e.g.
> lost of ssh after moving network, end of credential after
> a timeout for sudo...) In this case, I use
> 'tramp-cleanup-all-connections' but this will also close any
> *Man* buffers with this default-directory.

Interesting, why do you do `tramp-cleanup-all-connections'?

Anyway, when I do

  M-x man RET man RET

and then

  M-x tramp-cleanup-all-connections RET

the man buffer is still there.

Sounds like maybe you are doing the man page view in
a remote shell?

Otherwise, I don't see why those should be related ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[Michael Albinus]

Manuel Giraud via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Hi,

Hi Manual,

> Whenever Emacs creates a non file buffer (for instance with 'M-x man'),
> it sets its default-directory from the one of the buffer you are into.
> Most of the time, I don't think it matters but for remote buffers.
>
> A remote default-directory could go "disconnected" (e.g. lost of ssh
> after moving network, end of credential after a timeout for sudo...)  In
> this case, I use 'tramp-cleanup-all-connections' but this will also
> close any *Man* buffers with this default-directory.
>
> I don't have an idea or solution for this issue (that might not be one!)
> but I'd just like to know how others deal with this.

Perhaps tramp-cleanup-all-connections should close only buffers which
have a remote process or a remote buffer-file-name? Since I don't know
of unexpected side effects, this behavior could be controlled by a user
option?

> Thanks,

Best regards, Michael.

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Michael Albinus <michael.albinus@gmx.de> writes:

[...]

> Perhaps tramp-cleanup-all-connections should close only buffers which
> have a remote process or a remote buffer-file-name? Since I don't know
> of unexpected side effects, this behavior could be controlled by a user
> option?

Hi Michael,

Yes but then won't TRAMP keep trying to connect to the remote server or
ask for a password for those buffers that don't have a remote process or
file?  If so, maybe a better approach is that those kind of buffers
should get a "special" default-directory at startup... but there might
be cases where it is a bad idea.  I don't know.  That's why I asked this
question: I find it annoying but people might have ways to avoid it.

Best regards,
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Emanuel Berg]

Manuel Giraud via Users list for the GNU Emacs text editor wrote:

>> Perhaps tramp-cleanup-all-connections should close only
>> buffers which have a remote process or a remote
>> buffer-file-name? Since I don't know of unexpected side
>> effects, this behavior could be controlled by
>> a user option?
>
> Yes but then won't TRAMP keep trying to connect to the
> remote server or ask for a password for those buffers that
> don't have a remote process or file? If so, maybe a better
> approach is that those kind of buffers should get
> a "special" default-directory at startup... but there might
> be cases where it is a bad idea. I don't know. That's why
> I asked this question: I find it annoying but people might
> have ways to avoid it.

I just tried to use tramp, in that buffer, which shows a file
on a another, and different system, and then did

  M-x man RET man RET

and the local manpage came up, I then did
`tramp-cleanup-all-connections' and
`tramp-cleanup-all-buffers' and this does not affect the local
man page being displayed.

And why would it ... ha. I don't understand what you guys are
talking about ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Emanuel Berg <incal@dataswamp.org> writes:

[...]

> I just tried to use tramp, in that buffer, which shows a file
> on a another, and different system, and then did
>
>   M-x man RET man RET
>
> and the local manpage came up, I then did
> `tramp-cleanup-all-connections' and
> `tramp-cleanup-all-buffers' and this does not affect the local
> man page being displayed.

I did the same test and you're right `tramp-cleanup-all-connections'
does nothing to the buffers but `tramp-cleanup-all-buffers' kill the
remote dired (expected) *and* the man buffer.  So it does not work the
same as you: I'm going to try with emacs -Q.

As for why I'm using `tramp-cleanup-all-buffers': when I'm on another
network I know I cannot contact some host, TRAMP will sometimes hang
Emacs trying to connect anyway.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Manuel Giraud via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

[...]

> I did the same test and you're right `tramp-cleanup-all-connections'
> does nothing to the buffers but `tramp-cleanup-all-buffers' kill the
> remote dired (expected) *and* the man buffer.  So it does not work the
> same as you: I'm going to try with emacs -Q.

FTR, I have the same behaviour with emacs -Q.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Michael Albinus]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Hi Michael,

Hi Manual,

>> Perhaps tramp-cleanup-all-connections should close only buffers which
>> have a remote process or a remote buffer-file-name? Since I don't know
>> of unexpected side effects, this behavior could be controlled by a user
>> option?
>
> Yes but then won't TRAMP keep trying to connect to the remote server or
> ask for a password for those buffers that don't have a remote process or
> file?  If so, maybe a better approach is that those kind of buffers
> should get a "special" default-directory at startup... but there might
> be cases where it is a bad idea.  I don't know.  That's why I asked this
> question: I find it annoying but people might have ways to avoid it.

Usually, tramp-cleanup-all-connections is sufficient.
tramp-cleanup-all-buffers let the remote buffers disappear in order to
not let you reconnect via a mistake, like openening a file in dired.

We could improve my proposal by adding a hook, which tells you which
buffers to remove. This hook could contain predicates for checking a
remote buffer-file-name, a remote process, or a romete dired buffer. And
this might be a new command in parallel to
tramp-cleanup-all-{buffers,connections}.  Whether this is sufficient
we'll see, but this mechanism could be tuned after first experiences.

> Best regards,

Best regards, Michael.

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Michael Albinus <michael.albinus@gmx.de> writes:

[...]

> Usually, tramp-cleanup-all-connections is sufficient.
> tramp-cleanup-all-buffers let the remote buffers disappear in order to
> not let you reconnect via a mistake, like openening a file in dired.

Ok.  I didn't know about that so maybe I could live with that using
`tramp-cleanup-all-connections' only.

> We could improve my proposal by adding a hook, which tells you which
> buffers to remove. This hook could contain predicates for checking a
> remote buffer-file-name, a remote process, or a romete dired buffer. And
> this might be a new command in parallel to
> tramp-cleanup-all-{buffers,connections}.  Whether this is sufficient
> we'll see, but this mechanism could be tuned after first experiences.

Even if `tramp-cleanup-all-connections' is enough, I think that it is a
good idea.  It would keep closing a "remote" non [file|process|dired]
from happening.  But Emanuel Berg said it does not see this behaviour
with `tramp-cleanup-all-buffers': am I the only one?

Recipe:
        - C-x d /-:remotehost:
        - M-x man man
        - M-x tramp-cleanup-all-buffers

Is the *Man man* buffer closed?
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Emanuel Berg]

Manuel Giraud via Users list for the GNU Emacs text editor wrote:

> Ok. I didn't know about that so maybe I could live with that
> using `tramp-cleanup-all-connections' only.

Again, you having to do that manually and repeatedly, what
problem does that indicate? Don't know but I would start
thinking from there as well ...

>> We could improve my proposal by adding a hook, which tells
>> you which buffers to remove. This hook could contain
>> predicates for checking a remote buffer-file-name, a remote
>> process, or a romete dired buffer. And this might be a new
>> command in parallel to
>> tramp-cleanup-all-{buffers,connections}. Whether this is
>> sufficient we'll see, but this mechanism could be tuned
>> after first experiences.
>
> Even if `tramp-cleanup-all-connections' is enough, I think
> that it is a good idea. It would keep closing a "remote" non
> [file|process|dired] from happening. But Emanuel Berg said
> it does not see this behaviour with
> `tramp-cleanup-all-buffers': am I the only one?
>
> Recipe:
>         - C-x d /-:remotehost:
>         - M-x man man
>         - M-x tramp-cleanup-all-buffers
>
> Is the *Man man* buffer closed?

Aha, `dired'! \o/

That's it then, I did `find-file' with tramp.

No, you are right, if you do it with dired it happens as you
say and the reason is (again as you say) the
`default-directory' inheritance.

Bug unless/until someone does a super-cool man page interface
which then would would ask - local or remote man page for
find(1) ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Emanuel Berg <incal@dataswamp.org> writes:

[...]

>> Recipe:
>>         - C-x d /-:remotehost:
>>         - M-x man man
>>         - M-x tramp-cleanup-all-buffers
>>
>> Is the *Man man* buffer closed?
>
> Aha, `dired'! \o/
>
> That's it then, I did `find-file' with tramp.
>
> No, you are right, if you do it with dired it happens as you
> say and the reason is (again as you say) the
> `default-directory' inheritance.

Strange.  I tried with find-file on a remote file and the *Man man* is
closed too.  I think there is `default-directory' inheritance here also.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Emanuel Berg]

Manuel Giraud via Users list for the GNU Emacs text editor wrote:

>>> Recipe:
>>>         - C-x d /-:remotehost:
>>>         - M-x man man
>>>         - M-x tramp-cleanup-all-buffers
>>>
>>> Is the *Man man* buffer closed?
>>
>> Aha, `dired'! \o/
>>
>> That's it then, I did `find-file' with tramp.
>>
>> No, you are right, if you do it with dired it happens as
>> you say and the reason is (again as you say) the
>> `default-directory' inheritance.
>
> Strange. I tried with find-file on a remote file and the
> *Man man* is closed too. I think there is
> `default-directory' inheritance here also.

Yes, maybe I switched buffer in the excitement ...

So the man page browser gets the affected directory, but still
shows man pages from the local system. So either it should
show man pages from the remote system or it should reset its
`default-directory' when fetching a local?

I still think using `tramp-cleanup-all-buffers' manually all
the time indicates some other problem ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[Michael Albinus]

Emanuel Berg <incal@dataswamp.org> writes:

Hi Emanuel,

> Yes, maybe I switched buffer in the excitement ...
>
> So the man page browser gets the affected directory, but still
> shows man pages from the local system. So either it should
> show man pages from the remote system or it should reset its
> `default-directory' when fetching a local?

Supporting remote man pages is on my TODO, unfortunately with low
priority only.

> I still think using `tramp-cleanup-all-buffers' manually all
> the time indicates some other problem ...

Yes. For example switching between home office and work
office. Something, you cannot blame Tramp for :-)

Best regards, Michael.

Re: Non file buffers and default-directory

[Emanuel Berg]

Michael Albinus wrote:

>> So the man page browser gets the affected directory, but
>> still shows man pages from the local system. So either it
>> should show man pages from the remote system or it should
>> reset its `default-directory' when fetching a local?
>
> Supporting remote man pages is on my TODO, unfortunately
> with low priority only.

You have interesting items on that list!

>> I still think using `tramp-cleanup-all-buffers' manually
>> all the time indicates some other problem ...
>
> Yes. For example switching between home office and work
> office. Something, you cannot blame Tramp for :-)

Right. I forgot work is something done :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[Marcin Borkowski]

On 2023-04-20, at 17:11, Manuel Giraud via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> [...] am I the only one?

Nope.  I was too lazy to look for the reason (so thanks for finding that
out for me!), since it didn't happen very often, but it's /very/
frustrating when it happens - basically, I can't do anything and my
Emacs is blocked (especially if I TRAMPed to a machine in my office
I don't have access to at home, for instance).

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2023-04-20, at 17:11, Manuel Giraud via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
>> [...] am I the only one?
>
> Nope.  I was too lazy to look for the reason (so thanks for finding that
> out for me!), since it didn't happen very often, but it's /very/
> frustrating when it happens - basically, I can't do anything and my
> Emacs is blocked (especially if I TRAMPed to a machine in my office
> I don't have access to at home, for instance).

Hi,

Here I was just talking about the fact that 'tramp-cleanup-all-buffers'
will close any buffer with a remote 'default-directory' (even the ones
not connected to a file, a directory or a process).

But you're right that it is somewhat related to the issue you're talking
about: my need to call 'tramp-cleanup-all-connections' or
'tramp-cleanup-all-buffers' also comes from those hangs.  So for your
issue, as Michael suggested, you could try calling
'tramp-cleanup-all-connections' when at home.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Michael Albinus]

Marcin Borkowski <mbork@mbork.pl> writes:

Hi Marcin,

> Nope.  I was too lazy to look for the reason (so thanks for finding that
> out for me!), since it didn't happen very often, but it's /very/
> frustrating when it happens - basically, I can't do anything and my
> Emacs is blocked (especially if I TRAMPed to a machine in my office
> I don't have access to at home, for instance).

For this very use case, Tramp offers the commands tramp-rename-files and
tramp-rename-these-files. See (info "(tramp) Renaming remote files")

Yes, I know, almost nobody reads manuals. But perhaps you give it a try?

> Best,

Best regards, Michael.

Re: Non file buffers and default-directory

[Marcin Borkowski]

On 2023-04-21, at 10:01, Michael Albinus <michael.albinus@gmx.de> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
> Hi Marcin,
>
>> Nope.  I was too lazy to look for the reason (so thanks for finding that
>> out for me!), since it didn't happen very often, but it's /very/
>> frustrating when it happens - basically, I can't do anything and my
>> Emacs is blocked (especially if I TRAMPed to a machine in my office
>> I don't have access to at home, for instance).
>
> For this very use case, Tramp offers the commands tramp-rename-files and
> tramp-rename-these-files. See (info "(tramp) Renaming remote files")
>
> Yes, I know, almost nobody reads manuals. But perhaps you give it a try?

Well, you speak to one of the 10 people in the world who actually read
the Emacs manual.  (And that might be in binary.)

Joking aside, I should probably read TRAMP manual, too.  (I read the
Emacs one more than two decades ago, when I had much more time as
a student...)

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Michael Albinus <michael.albinus@gmx.de> writes:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
> Hi Marcin,
>
>> Nope.  I was too lazy to look for the reason (so thanks for finding that
>> out for me!), since it didn't happen very often, but it's /very/
>> frustrating when it happens - basically, I can't do anything and my
>> Emacs is blocked (especially if I TRAMPed to a machine in my office
>> I don't have access to at home, for instance).
>
> For this very use case, Tramp offers the commands tramp-rename-files and
> tramp-rename-these-files. See (info "(tramp) Renaming remote files")
>
> Yes, I know, almost nobody reads manuals. But perhaps you give it a
> try?

Wow, I guess I should have read the manual :-) This seems powerful but
maybe a little bit convoluted.  And most of the time, I do not need the
remote files elsewhere (i.e. they are on this remote host for a reason
after all).  And then there is the issue of getting those files « back »
to the remote host.  So I think I'll stick to
`tramp-cleanup-all-connections' but it is impressive to see what TRAMP
could do.

Best regards,
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Michael Albinus]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

Hi Manual,

> Wow, I guess I should have read the manual :-) This seems powerful but
> maybe a little bit convoluted.  And most of the time, I do not need the
> remote files elsewhere (i.e. they are on this remote host for a reason
> after all).  And then there is the issue of getting those files « back »
> to the remote host.  So I think I'll stick to
> `tramp-cleanup-all-connections' but it is impressive to see what TRAMP
> could do.

Sure, everybody applies the scenario which fits best. tramp-rename*-files 
were introduced by suggestion of a user, who also switches often between
home and work office, and who wanted to get access to the files in the
*other* office.

Anyway, I'm frustrated by trying (again) to add threads for Tramp. No real
progress for weeks. So I need a break, and tramp-cleanup-some-buffers
seems easy enough to implement, and it would enjoy me to do this.

> Best regards,

Best regards, Michael.

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Michael Albinus <michael.albinus@gmx.de> writes:

[...]

> Anyway, I'm frustrated by trying (again) to add threads for Tramp. No real
> progress for weeks. So I need a break, and tramp-cleanup-some-buffers
> seems easy enough to implement, and it would enjoy me to do this.

😄 Have a nice break then.  (I thought that Emacs did not have "real"
parallel threads and that only external async process provided some
parallelism).

Anyway, if I understood you correctly 'tramp-cleanup-some-buffers' will
close tramp buffers that validates a user configurable hook?
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Eli Zaretskii]

> Cc: Marcin Borkowski <mbork@mbork.pl>,  Manuel Giraud via Users list for the
>  GNU Emacs text editor <help-gnu-emacs@gnu.org>
> Date: Sat, 22 Apr 2023 15:56:20 +0200
> From:  Manuel Giraud via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
> > Anyway, I'm frustrated by trying (again) to add threads for Tramp. No real
> > progress for weeks. So I need a break, and tramp-cleanup-some-buffers
> > seems easy enough to implement, and it would enjoy me to do this.
> 
> 😄 Have a nice break then.  (I thought that Emacs did not have "real"
> parallel threads and that only external async process provided some
> parallelism).

Tramp is all about starting async sub-processes, though.  So it should
be one of the ideal candidates for using Lisp threads.

Re: Non file buffers and default-directory

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Tramp is all about starting async sub-processes, though.  So it should
> be one of the ideal candidates for using Lisp threads.

I thought that Tramp was already using async processes.  What would be
the use for Lisp threads then.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Michael Albinus]

Manuel Giraud <manuel.giraud@univ-nantes.fr> writes:

Hi Manual,

>> Tramp is all about starting async sub-processes, though.  So it should
>> be one of the ideal candidates for using Lisp threads.
>
> I thought that Tramp was already using async processes.  What would be
> the use for Lisp threads then.

My first attempt, years ago, was to unblock Emacs in case Tramp reads or
writes large remote files. This was oursorced to a thread, and it worked
somehow except when there was user interaction required.

My new approach is less ambiguous. It tries to solve the problem when
the Tramp process buffer is used in parallel from different places, due
to file access from timers, process filters, process sentinels, and alike.

Best regards, Michael.

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  help-gnu-emacs@gnu.org
> Date: Sun, 23 Apr 2023 09:22:46 +0200
> 
> My first attempt, years ago, was to unblock Emacs in case Tramp reads or
> writes large remote files. This was oursorced to a thread, and it worked
> somehow except when there was user interaction required.

Can you share your experience from that attempt?  Why wasn't it
working well when user interaction was required?

Btw, if someone is looking for a worthy development task which could
be handled by threads, I have one: make smtpmail-send-it run from a
thread, thus avoiding to lock up Emacs until the email message is sent
(or fails to be sent).  This is especially important when the link is
flaky, in which case sending an email message could lock up Emacs for
many seconds.

Re: Non file buffers and default-directory

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Btw, if someone is looking for a worthy development task which could
> be handled by threads, I have one: make smtpmail-send-it run from a
> thread, thus avoiding to lock up Emacs until the email message is sent
> (or fails to be sent).  This is especially important when the link is
> flaky, in which case sending an email message could lock up Emacs for
> many seconds.

Do you mean smtpmail-send-it itself or a caller of smtpmail-send-it?  And
if so which one?
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Manuel Giraud <help-gnu-emacs@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 23 Apr 2023 13:24:08 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, if someone is looking for a worthy development task which could
> > be handled by threads, I have one: make smtpmail-send-it run from a
> > thread, thus avoiding to lock up Emacs until the email message is sent
> > (or fails to be sent).  This is especially important when the link is
> > flaky, in which case sending an email message could lock up Emacs for
> > many seconds.
> 
> Do you mean smtpmail-send-it itself or a caller of smtpmail-send-it?  And
> if so which one?

I mean smtpmail-send-it.  Specifically, its subroutine
smtpmail-via-smtp, which is what actually sends the email.

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Btw, if someone is looking for a worthy development task which could
> be handled by threads, I have one: make smtpmail-send-it run from a
> thread, thus avoiding to lock up Emacs until the email message is sent
> (or fails to be sent).  This is especially important when the link is
> flaky, in which case sending an email message could lock up Emacs for
> many seconds.

FTR, I've tried the following:
--8<---------------cut here---------------start------------->8---
(defun my-send-mail-function ()
  (make-thread #'smtpmail-send-it))

(setq send-mail-function 'my-send-mail-function)
--8<---------------cut here---------------end--------------->8---

This seems to work but I guess that you were thinking of something else.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 23 Apr 2023 13:46:32 +0200
> 
> FTR, I've tried the following:
> --8<---------------cut here---------------start------------->8---
> (defun my-send-mail-function ()
>   (make-thread #'smtpmail-send-it))
> 
> (setq send-mail-function 'my-send-mail-function)
> --8<---------------cut here---------------end--------------->8---
> 
> This seems to work but I guess that you were thinking of something else.

"Work" in what sense?  Were you able to do something in Emacs while
the mail was being sent?  What happens if the send fails for some
reason?  And how fast is it sent in your case, so that the "work" part
could be evaluated in real-life conditions, when sending takes some
time?  For example, what happens if you try to send a message with a
very large attachment?

Thread for smtpmail-send-it (was: Non file buffers and default-directory)

[Manuel Giraud via Users list for the GNU Emacs text editor]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Sun, 23 Apr 2023 13:46:32 +0200
>> 
>> FTR, I've tried the following:
>> --8<---------------cut here---------------start------------->8---
>> (defun my-send-mail-function ()
>>   (make-thread #'smtpmail-send-it))
>> 
>> (setq send-mail-function 'my-send-mail-function)
>> --8<---------------cut here---------------end--------------->8---
>> 
>> This seems to work but I guess that you were thinking of something else.
>
> "Work" in what sense?  Were you able to do something in Emacs while
> the mail was being sent?  What happens if the send fails for some
> reason?  And how fast is it sent in your case, so that the "work" part
> could be evaluated in real-life conditions, when sending takes some
> time?  For example, what happens if you try to send a message with a
> very large attachment?

"Work" in the sense that the mail arrived in my mailbox.  But this goes
too fast to evaluate anything else.  Maybe I could try with a fake and
slow SMTP server.
-- 
Manuel Giraud

Re: Thread for smtpmail-send-it (was: Non file buffers and default-directory)

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 23 Apr 2023 16:48:25 +0200
> 
> >> This seems to work but I guess that you were thinking of something else.
> >
> > "Work" in what sense?  Were you able to do something in Emacs while
> > the mail was being sent?  What happens if the send fails for some
> > reason?  And how fast is it sent in your case, so that the "work" part
> > could be evaluated in real-life conditions, when sending takes some
> > time?  For example, what happens if you try to send a message with a
> > very large attachment?
> 
> "Work" in the sense that the mail arrived in my mailbox.  But this goes
> too fast to evaluate anything else.  Maybe I could try with a fake and
> slow SMTP server.

Yes, when the email is sent fast, there's no need for a separate
thread.

I suggest to try sending a large attachment, and while the email is
being sent, try editing something and see if Emacs is responsive.

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Sun, 23 Apr 2023 13:46:32 +0200
>> 
>> FTR, I've tried the following:
>> --8<---------------cut here---------------start------------->8---
>> (defun my-send-mail-function ()
>>   (make-thread #'smtpmail-send-it))
>> 
>> (setq send-mail-function 'my-send-mail-function)
>> --8<---------------cut here---------------end--------------->8---
>> 
>> This seems to work but I guess that you were thinking of something else.
>
> "Work" in what sense?  Were you able to do something in Emacs while
> the mail was being sent?  What happens if the send fails for some
> reason?  And how fast is it sent in your case, so that the "work" part
> could be evaluated in real-life conditions, when sending takes some
> time?  For example, what happens if you try to send a message with a
> very large attachment?

Hi,

FWIW, I've made some tests with this simplistic setup (just a
make-thread on smtpmail-send-it) and a toy SMTP server of mine.  This
server makes some random pause (50ms max) for each line it received.

The message had an image attachment to it resulting in many lines of
base64 encoded text.  So this mail takes about 12 minutes to send.

The good:

        - while doing this, Emacs was fully responsive: I have read some
          mails in Gnus, edit an org file, export it to PDF, delete
          files from dired...

The bad (and ugly):

        - the mail is considered *sent* right away even if the server
          hangs up in the middle of the transaction and the message is
          not sent :-/
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 25 Apr 2023 19:00:25 +0200
> 
> The good:
> 
>         - while doing this, Emacs was fully responsive: I have read some
>           mails in Gnus, edit an org file, export it to PDF, delete
>           files from dired...
> 
> The bad (and ugly):
> 
>         - the mail is considered *sent* right away even if the server
>           hangs up in the middle of the transaction and the message is
>           not sent :-/

Thanks.  This is promising, but it also means that some changes are
needed in smtpmail-send-it to avoid the bad and the ugly part.  (And
further discussions should probably move to emacs-devel.)

Thank you for doing this, I think it will be a very important feature
when it becomes available.

Re: Non file buffers and default-directory

[Emanuel Berg]

Eli Zaretskii wrote:

> Thanks. This is promising, but it also means that some
> changes are needed in smtpmail-send-it to avoid the bad and
> the ugly part. (And further discussions should probably move
> to emacs-devel.)
>
> Thank you for doing this, I think it will be a very
> important feature when it becomes available.

How do you do a defun with any/arbitrary Elisp code and call
it without Emacs becoming nonresponsive executing the code, no
matter how simple/complex, for the duration of the time the
code is executing?

Note that if this period is prolonged because of
"non-nonresponsive" interactive activity outside of this code,
such a prolongment, slim or big, is okay in this sense
(prevent nonresponsiveness), as that is another issue.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Tue, 25 Apr 2023 19:54:56 +0200
> 
> Eli Zaretskii wrote:
> 
> > Thanks. This is promising, but it also means that some
> > changes are needed in smtpmail-send-it to avoid the bad and
> > the ugly part. (And further discussions should probably move
> > to emacs-devel.)
> >
> > Thank you for doing this, I think it will be a very
> > important feature when it becomes available.
> 
> How do you do a defun with any/arbitrary Elisp code and call
> it without Emacs becoming nonresponsive executing the code, no
> matter how simple/complex, for the duration of the time the
> code is executing?

You use Lisp threads.  If done correctly, Emacs will respond to user
input while another thread is waiting for a sub-process (in this case,
network connection to the SMTP server) to produce output.  See the
node "Threads" in the ELisp Reference manual.

> Note that if this period is prolonged because of
> "non-nonresponsive" interactive activity outside of this code,
> such a prolongment, slim or big, is okay in this sense
> (prevent nonresponsiveness), as that is another issue.

Parse error.

Re: Non file buffers and default-directory

[Emanuel Berg]

Eli Zaretskii wrote:

> You use Lisp threads. If done correctly, Emacs will respond
> to user input while another thread is waiting for
> a sub-process (in this case, network connection to the SMTP
> server) to produce output.

Example for a hello world defun would perhaps help.

If that is easy I don't see why a more complicated process
that you wish to isolate in the same way, why that should be
more complicated just because the process is?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Thu, 27 Apr 2023 21:46:51 +0200
> 
> Eli Zaretskii wrote:
> 
> > You use Lisp threads. If done correctly, Emacs will respond
> > to user input while another thread is waiting for
> > a sub-process (in this case, network connection to the SMTP
> > server) to produce output.
> 
> Example for a hello world defun would perhaps help.

There are examples in the ELisp manual, and more in the test suite.

> If that is easy I don't see why a more complicated process
> that you wish to isolate in the same way, why that should be
> more complicated just because the process is?

Sorry, I don't understand what you are saying (or asking?) here.

Re: Non file buffers and default-directory

[Emanuel Berg]

Eli Zaretskii wrote:

>>> You use Lisp threads. If done correctly, Emacs will
>>> respond to user input while another thread is waiting for
>>> a sub-process (in this case, network connection to the
>>> SMTP server) to produce output.
>> 
>> Example for a hello world defun would perhaps help.
>
> There are examples in the ELisp manual, and more in the test suite.
>
>> If that is easy I don't see why a more complicated process
>> that you wish to isolate in the same way, why that should
>> be more complicated just because the process is?
>
> Sorry, I don't understand what you are saying (or
> asking?) here.

I mean, relax man, maybe show us some simplest implementation
"hello world" ...

Because ... that would be really cool for us to see!

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[tomas]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

On Mon, May 01, 2023 at 04:10:04AM +0200, Emanuel Berg wrote:

[...]

> I mean, relax man, maybe show us some simplest implementation
> "hello world" ...

(defun hello-world ()
  (message "Hello, World"))

Happy now?

(SCNR)
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Non file buffers and default-directory

[Emanuel Berg]

tomas wrote:

>> maybe show us some simplest implementation "hello world" [...]
>
> (defun hello-world ()
>   (message "Hello, World"))
>
> Happy now?

No, since that should just execute sequentially and monopolize
the Emacs process if I am correct?

Also, if we can have threads one should go thro one's Elisp
and think what computing can be decoupled that way. Maybe I'm
a narrow-minded Elisp programmer, but I think at least for my
Elisp, there are not a lot that would benefit from that kind
of decoupling. But I might be wrong.

Also, I don't know if this can be done more under the hood so
that and could have `let-thread', i.e. a `let' (not `let*')
that is parallel.

But again for practical purposes, for all background data
crunching one would typically rely on the underlying Unix.
And in Emacs we already have the idle timer. So between that
Unix crunching (that has nothing to do with editing) and the
Emacs idle timer, it would be interesting to see what "target
audience" there is for threads in Emacs.

What scheduler is employed BTW or are you supposed to
synchronize manually? If so, or both of them actually, I'm
even more interested in finding out what kind of computing is
benefitted from this?

AI, maybe?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

On Tue, May 02, 2023 at 12:15:14AM +0200, Emanuel Berg wrote:
> tomas wrote:
> 
> >> maybe show us some simplest implementation "hello world" [...]
> >
> > (defun hello-world ()
> >   (message "Hello, World"))
> >
> > Happy now?
> 
> No, since that should just execute sequentially and monopolize
> the Emacs process if I am correct?

[...]

Your request is far too unspecific as to allow a
meaningful answer. What do you mean by a "thread"?
What do you expect "parallel" to do"? How do your
programs look like? Do you want multiprocessing with
explicit continuation passing or with pseudo- or
real parallelism with locking around commonly shared
resources? Or do rather message passing without
any shared resources?

"Threads" is not just some kind of magical dust
you sprinkle over your program to make it execute
in parallel, alas.

For one extreme of the spectrum, making a program
responsive while waiting for data to trickle in
via several network sockets doesn't need any
threads (arguably, threads can make it worse, as
web server folks have proven).

On the other extreme, you might want to distribute
a big parallelizable work to your 40 CPU cores
(I only have 2, alas). Most of the time,you'd be
better of with many processes.

Life takes place somewhere in between that (unless
you are either working with big clusters, or with
GPUs).

My take is that threads are a bit overrated.
But I may be wrong.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Non file buffers and default-directory

[Emanuel Berg]

tomas wrote:

> Your request is far too unspecific as to allow a meaningful
> answer. What do you mean by a "thread"?

The Emacs threads, it would be interesting to see examples of
how it solves problems in a distributed or parallel way ...
or a way that is more fail safe, maybe? Whatever the
advantage is in that case ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Mon, 01 May 2023 04:10:04 +0200
> 
> Eli Zaretskii wrote:
> 
> >> Example for a hello world defun would perhaps help.
> >
> > There are examples in the ELisp manual, and more in the test suite.
> >
> >> If that is easy I don't see why a more complicated process
> >> that you wish to isolate in the same way, why that should
> >> be more complicated just because the process is?
> >
> > Sorry, I don't understand what you are saying (or
> > asking?) here.
> 
> I mean, relax man, maybe show us some simplest implementation
> "hello world" ...
> 
> Because ... that would be really cool for us to see!

Then I already answered that, above.

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Thanks.  This is promising, but it also means that some changes are
> needed in smtpmail-send-it to avoid the bad and the ugly part.  (And
> further discussions should probably move to emacs-devel.)
>
> Thank you for doing this, I think it will be a very important feature
> when it becomes available.

Hi Eli,

Thanks for your support.  I'm reading some code now and I start to
realize that *just* having an async SMTP sender in Emacs won't be that
easy.

An example: I'm using Gnus (and message.el) to send mail.  If you look
at 'message-send' (lisp/gnus/message.el#4396), that I guess is calling
'smtpmail-send-it' down the line, you'll see that it is "waiting" for a
synchronous 'success' to decide what to do next (for example, renaming
the buffer from *unsent...* to *sent...*).  This won't work as is with
an async SMTP sender.  I imagine that there are other places with code
like that and that it could break many workflow.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Thu, 27 Apr 2023 12:58:15 +0200
> 
> Thanks for your support.  I'm reading some code now and I start to
> realize that *just* having an async SMTP sender in Emacs won't be that
> easy.
> 
> An example: I'm using Gnus (and message.el) to send mail.  If you look
> at 'message-send' (lisp/gnus/message.el#4396), that I guess is calling
> 'smtpmail-send-it' down the line, you'll see that it is "waiting" for a
> synchronous 'success' to decide what to do next (for example, renaming
> the buffer from *unsent...* to *sent...*).  This won't work as is with
> an async SMTP sender.  I imagine that there are other places with code
> like that and that it could break many workflow.

I know it is not easy, right?  Basically, the function(s) that
actually send the email will have to be broken into two: one that
prepares the message, the other which actually sends it.  It's the
latter that needs to run from a separate thread.  in addition, there
should be some callback that marks the message as sent, and does
whatever else bookkeeping is needed when the send succeeds or fails,
like, for example, if this is a response, marking the original message
as one that was replied-to.

Re: Non file buffers and default-directory

[Tim Landscheidt]

Eli Zaretskii <eliz@gnu.org> wrote:

>> Thanks for your support.  I'm reading some code now and I start to
>> realize that *just* having an async SMTP sender in Emacs won't be that
>> easy.

>> An example: I'm using Gnus (and message.el) to send mail.  If you look
>> at 'message-send' (lisp/gnus/message.el#4396), that I guess is calling
>> 'smtpmail-send-it' down the line, you'll see that it is "waiting" for a
>> synchronous 'success' to decide what to do next (for example, renaming
>> the buffer from *unsent...* to *sent...*).  This won't work as is with
>> an async SMTP sender.  I imagine that there are other places with code
>> like that and that it could break many workflow.

> I know it is not easy, right?  Basically, the function(s) that
> actually send the email will have to be broken into two: one that
> prepares the message, the other which actually sends it.  It's the
> latter that needs to run from a separate thread.  in addition, there
> should be some callback that marks the message as sent, and does
> whatever else bookkeeping is needed when the send succeeds or fails,
> like, for example, if this is a response, marking the original message
> as one that was replied-to.

Side note: I would love a well-maintained example of an
"asynchronous" user interface in Emacs.

I have a bunch of shell/Perl/Python scripts that I'd like to
convert to Emacs Lisp for a consistent UI that can also be
used over SSH.

For example, I have a script that plays a podcast's audio
file and afterwards asks me if the associated database entry
selected from a list of suggestions should be marked as
heard (and the file archived).  I also use this as part of
sequences, i. e. "$script file1.mp3 && $script file2.mp3".

Now in Emacs, I obviously would want to continue to work on
something else while the audio is playing in the background.
I also don't want that other work to be interrupted in the
sense of a blocking minibuffer prompt when the playback has
finished.  And I also don't want to accidentally quit Emacs
without me being reminded, "hey, that playback has finished,
should it be marked as heard?"  And I want that "bit" to be
usable as part of a sequence, i. e. after answering the
question, the next statement should be executed.

Probably, one can achieve something like this with promises
(e. g., https://github.com/chuntaro/emacs-promise), but as
they are not part of core Emacs and also rather complex, I
don't feel very comfortable to base my workflows on that.

Tim

Re: Non file buffers and default-directory

[Eli Zaretskii]

> From: Tim Landscheidt <tim@tim-landscheidt.de>
> Date: Thu, 27 Apr 2023 12:04:48 +0000
> 
> Side note: I would love a well-maintained example of an
> "asynchronous" user interface in Emacs.
> 
> I have a bunch of shell/Perl/Python scripts that I'd like to
> convert to Emacs Lisp for a consistent UI that can also be
> used over SSH.
> 
> For example, I have a script that plays a podcast's audio
> file and afterwards asks me if the associated database entry
> selected from a list of suggestions should be marked as
> heard (and the file archived).  I also use this as part of
> sequences, i. e. "$script file1.mp3 && $script file2.mp3".
> 
> Now in Emacs, I obviously would want to continue to work on
> something else while the audio is playing in the background.
> I also don't want that other work to be interrupted in the
> sense of a blocking minibuffer prompt when the playback has
> finished.  And I also don't want to accidentally quit Emacs
> without me being reminded, "hey, that playback has finished,
> should it be marked as heard?"  And I want that "bit" to be
> usable as part of a sequence, i. e. after answering the
> question, the next statement should be executed.

AFAIU, this has nothing to do with Lisp threads.  Every modern OS is
capable of playing audio/video clips in the background, so all you
need is invoke your player (or the script which invokes the player) in
that background mode.

Re: Non file buffers and default-directory

[Tim Landscheidt]

Eli Zaretskii <eliz@gnu.org> wrote:

> […]

> AFAIU, this has nothing to do with Lisp threads.  Every modern OS is
> capable of playing audio/video clips in the background, so all you
> need is invoke your player (or the script which invokes the player) in
> that background mode.

One can also send mails with a local MTA and/or do so with-
out Lisp threads but with conventional callbacks, so I as-
sumed this thread's topic had shifted slightly to more gen-
eral aspects of asynchronicity in Emacs.

Tim

Re: Non file buffers and default-directory

[Tomas Hlavaty]

On Thu 27 Apr 2023 at 12:04, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
> Side note: I would love a well-maintained example of an
> "asynchronous" user interface in Emacs.

This is easy if you are writing it from scratch.
It is not easy if you are talking about existing code.

> I have a bunch of shell/Perl/Python scripts that I'd like to
> convert to Emacs Lisp for a consistent UI that can also be
> used over SSH.
>
> For example, I have a script that plays a podcast's audio
> file and afterwards asks me if the associated database entry
> selected from a list of suggestions should be marked as
> heard (and the file archived).  I also use this as part of
> sequences, i. e. "$script file1.mp3 && $script file2.mp3".
>
> Now in Emacs, I obviously would want to continue to work on
> something else while the audio is playing in the background.
> I also don't want that other work to be interrupted in the
> sense of a blocking minibuffer prompt when the playback has
> finished.  And I also don't want to accidentally quit Emacs
> without me being reminded, "hey, that playback has finished,
> should it be marked as heard?"  And I want that "bit" to be
> usable as part of a sequence, i. e. after answering the
> question, the next statement should be executed.

Why not simply start a separate Emacs process and play the podcasts
there?

Re: Non file buffers and default-directory

[Tim Landscheidt]

Tomas Hlavaty <tom@logand.com> wrote:

>> Side note: I would love a well-maintained example of an
>> "asynchronous" user interface in Emacs.

> This is easy if you are writing it from scratch.
> It is not easy if you are talking about existing code.

Great, I'm looking for the "easy" one :-).  Any pointers?

>> I have a bunch of shell/Perl/Python scripts that I'd like to
>> convert to Emacs Lisp for a consistent UI that can also be
>> used over SSH.

>> For example, I have a script that plays a podcast's audio
>> file and afterwards asks me if the associated database entry
>> selected from a list of suggestions should be marked as
>> heard (and the file archived).  I also use this as part of
>> sequences, i. e. "$script file1.mp3 && $script file2.mp3".

>> Now in Emacs, I obviously would want to continue to work on
>> something else while the audio is playing in the background.
>> I also don't want that other work to be interrupted in the
>> sense of a blocking minibuffer prompt when the playback has
>> finished.  And I also don't want to accidentally quit Emacs
>> without me being reminded, "hey, that playback has finished,
>> should it be marked as heard?"  And I want that "bit" to be
>> usable as part of a sequence, i. e. after answering the
>> question, the next statement should be executed.

> Why not simply start a separate Emacs process and play the podcasts
> there?

Because then I wouldn't have one Emacs instance, but two (or
more) that I would have to switch between either in Screen
or with a window manager.  I want to have one unified Emacs
"control center" that I don't have to leave and where I can
integrate all aspects of Emacs "life" together, e. g., start
some workflow on an article's body when I read it in Gnus,
queue some other processes when the first one is finished,
feed the output to some other workflow/org-mode task/Gnus
mail, etc.

Tim

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> I know it is not easy, right?

Yes, I know.

> Basically, the function(s) that actually send the email will have to
> be broken into two: one that prepares the message, the other which
> actually sends it.  It's the latter that needs to run from a separate
> thread.  in addition, there should be some callback that marks the
> message as sent, and does whatever else bookkeeping is needed when the
> send succeeds or fails, like, for example, if this is a response,
> marking the original message as one that was replied-to.

Yes this interface seems right... but, and that was my point, you'll
need it in many places.  For example, if you work at 'smtpmail-send-it'
level, you would try to make 'smtpmail-via-smtp' async and have a
callback for its bookkeeping.  But then, you'll also need a way to add
the bookkeeping of higher level calls (for instance, 'message-send').

I start to see why modifying something to be async in Emacs should be
scrutinize to see if it worth the effort because you'll lose easy
programming and compositing in the process.

Anyway, I'll keep trying for the SMTP sender.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Tomas Hlavaty]

On Thu 27 Apr 2023 at 12:58, Manuel Giraud via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> Thanks for your support.  I'm reading some code now and I start to
> realize that *just* having an async SMTP sender in Emacs won't be that
> easy.
>
> An example: I'm using Gnus (and message.el) to send mail.  If you look
> at 'message-send' (lisp/gnus/message.el#4396), that I guess is calling
> 'smtpmail-send-it' down the line, you'll see that it is "waiting" for a
> synchronous 'success' to decide what to do next (for example, renaming
> the buffer from *unsent...* to *sent...*).  This won't work as is with
> an async SMTP sender.  I imagine that there are other places with code
> like that and that it could break many workflow.

You might be after feedmail with feedmail-enable-queue.  Then you can
feedmail-run-the-queue, either started manually/synchronously in
separate emacs instance or use async-emacs function I sent recently:

   id:875yad240l.fsf@logand.com
   Subject: Re: continuation passing in Emacs vs. JUST-THIS-ONE
   Date: Mon, 03 Apr 2023 02:39:06 +0200

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Tramp is all about starting async sub-processes, though.  So it should
> be one of the ideal candidates for using Lisp threads.

I thought that Tramp was already using async processes.  What would be
the use for Lisp threads then.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Michael Albinus]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

Hi Manuel,

>> Anyway, I'm frustrated by trying (again) to add threads for Tramp. No real
>> progress for weeks. So I need a break, and tramp-cleanup-some-buffers
>> seems easy enough to implement, and it would enjoy me to do this.
>
> 😄 Have a nice break then.  (I thought that Emacs did not have "real"
> parallel threads and that only external async process provided some
> parallelism).

Right. The idea is to fix the famous "Forbidden reentrant call of Tramp"
problem. When there are two concurrent accesses to read Tramp output,
one of the functions shall be put into a thread, and that thread shall
wait until the first access is ready.

> Anyway, if I understood you correctly 'tramp-cleanup-some-buffers' will
> close tramp buffers that validates a user configurable hook?

Yes.

Best regards, Michael.

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2023-04-20, at 17:11, Manuel Giraud via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
>> [...] am I the only one?
>
> Nope.  I was too lazy to look for the reason (so thanks for finding that
> out for me!), since it didn't happen very often, but it's /very/
> frustrating when it happens - basically, I can't do anything and my
> Emacs is blocked (especially if I TRAMPed to a machine in my office
> I don't have access to at home, for instance).

Reading the code, maybe for this issue you could also consider
`tramp-connection-timeout' it globally defaults to 60 seconds and can be
set per methods via `tramp-methods'.
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Michael Albinus]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

Hi Manuel,

>> We could improve my proposal by adding a hook, which tells you which
>> buffers to remove. This hook could contain predicates for checking a
>> remote buffer-file-name, a remote process, or a romete dired buffer. And
>> this might be a new command in parallel to
>> tramp-cleanup-all-{buffers,connections}.  Whether this is sufficient
>> we'll see, but this mechanism could be tuned after first experiences.
>
> Even if `tramp-cleanup-all-connections' is enough, I think that it is a
> good idea.  It would keep closing a "remote" non [file|process|dired]
> from happening.

I've pushed the new command tramp-cleanup-some-buffers. As said, it
kills [file|process|dired] buffers. There is also the option
tramp-cleanup-some-buffers-hook, which allows you to configure this.

Best regards, Michael.

Re: Non file buffers and default-directory

[Manuel Giraud via Users list for the GNU Emacs text editor]

Michael Albinus <michael.albinus@gmx.de> writes:

[...]

> I've pushed the new command tramp-cleanup-some-buffers. As said, it
> kills [file|process|dired] buffers. There is also the option
> tramp-cleanup-some-buffers-hook, which allows you to configure this.

Hi Michael,

I have just tested it and it works as expected.  I also think that the
defaults in `tramp-cleanup-some-buffers-hook' are sensible.  Thanks!

Best regards,
-- 
Manuel Giraud

Re: Non file buffers and default-directory

[Emanuel Berg]

Michael Albinus wrote:

> Perhaps tramp-cleanup-all-connections should close only
> buffers which have a remote process or a remote
> buffer-file-name?

?

1. Why cleanup in the first place, why do this manually?

2. Why close man pages, if that's what happening, if they are
   opened on and from the local machine?

But this doesn't happen for me, I use tramp every day and man
pages - let's just say I used to use them - and now I only
remembers my misinterpretations, probably.

That, and more!

-- 
underground experts united
https://dataswamp.org/~incal