how to force auto-save of buffers not visiting files, right now?

how to force auto-save of buffers not visiting files, right now?

[hw]

Hi,

how do I force auto-saving of a particular buffer, or of all buffers,
that are not visiting a file, right now?

I would like to improve below function by auto-saving the backup:


(defun my-perltidy-replace (arg)
  "Replace the contents of the current buffer with the output of
perltidy, and make a backup of the current buffer."
  (interactive "P")
  (save-some-buffers)
  (let ((tidy_buffer (generate-new-buffer (generate-new-buffer-name (concat "TidyBackup-" (buffer-name))))))
    (with-current-buffer (buffer-name)
      ;; swapping the text can screw up linum mode with two buffers in
      ;; the same frame when automatically enabled by cperl-mode
      (linum-mode -1)
      (shell-command-on-region (point-min) (point-max) "perltidy --standard-output" tidy_buffer)
      (buffer-swap-text tidy_buffer))
    (with-current-buffer tidy_buffer
      (auto-save-mode nil)
      (cperl-mode))
    (linum-mode 1)
    (message "buffer contents replaced with output of perltidy; backup is in %s" tidy_buffer)))


I want an autosave of the backup once the buffer contents were swapped
to keep the original in case something goes wrong.  If nothing went
wrong, I'll eventually kill the buffer holding the backup, which is
why I don't want to save it to a file the buffer would be visiting
and which I would have to explicitly delete at some time (and because
some of the files would have to be saved on remote hosts, which would
make things rather unwieldy).

The problem is with "right now".  Without further ado, the backup is
automatically being saved after "a while", but I need it saved
"right now" since meanwhile, things can go wrong.

Or is this a bad idea?

Another question would be how I can copy all modes of a buffer and
apply them to another one.  Just enabling cperl-mode works for me,
but it's not really nice like this.  Somehow, that seems difficult
to do.

Re: how to force auto-save of buffers not visiting files, right now?

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Date: Mon, 14 Mar 2022 05:55:34 +0100
> 
> how do I force auto-saving of a particular buffer, or of all buffers,
> that are not visiting a file, right now?

"M-x do-auto-save RET"

As for buffers not visiting files: you should set that up separately,
e.g. by turning on the auto-save-mode in those buffers (manually or
otherwise).

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Mon, 2022-03-14 at 14:48 +0200, Eli Zaretskii wrote:
> > From: hw <hw@adminart.net>
> > Date: Mon, 14 Mar 2022 05:55:34 +0100
> > 
> > how do I force auto-saving of a particular buffer, or of all buffers,
> > that are not visiting a file, right now?
> 
> "M-x do-auto-save RET"
> 
> As for buffers not visiting files: you should set that up separately,
> e.g. by turning on the auto-save-mode in those buffers (manually or
> otherwise).
> 

Yes, and how do I make it so that a buffer not visiting a file is
being auto-saved without delay once the auto-save-mode has been
enabled?  Or can I make it auto-save once before enabling auto-save
mode?

Re: how to force auto-save of buffers not visiting files, right now?

[Jean Louis]

* hw <hw@adminart.net> [2022-03-15 08:22]:
> Yes, and how do I make it so that a buffer not visiting a file is
> being auto-saved without delay once the auto-save-mode has been
> enabled?  Or can I make it auto-save once before enabling auto-save
> mode?

Buffer not visiting file does not know where it should be saved. I am
using and doing something similar like you, I use buffers without file
names as additional scratch buffers. If Emacs session is over, those
temporary buffers are over. And I like sometimes to invoke them in
different mode, such as `sql-mode' or `emacs-lisp-mode'. Because they
are not connected to files, they can't be saved so easily.

(defvar rcd-temp-buffer-mode-history nil)
(defvar rcd-temp-file-directory "~/tmp/")
(defvar rcd-temp-buffer-name "RCD TEMPORARY BUFFER")
(defvar rcd-temp-buffer-modes '(("adoc-mode" . "adoc")
				("emacs-lisp-mode" . "el")
				("lisp-mode" . ".lisp")
				("markdown-mode" . ".md")
				("org-mode" . "org")
				("sql-mode" . "sql")
				("fundamental-mode" . "txt")
				("html-mode" . "html")))


(defun rcd-temp-buffer (&optional name mode)
  "Generate new temporary buffer."
  (interactive "p")
  (let* ((format (concat "*" rcd-temp-buffer-name "%s%s*"))
	 (buffer (if name (format format ": " name) (format format "" ""))))
    (switch-to-buffer (generate-new-buffer buffer))
    (if current-prefix-arg
	(let* ((mode (completing-read
		      "Mode: "
		      (map-keys rcd-temp-buffer-modes) nil t nil
		      'rcd-temp-buffer-mode-history)))
	  (funcall (intern mode)))
      (funcall (intern (or mode "fundamental-mode"))))))

and that function could be adopted to provide file names for buffers:

(defun rcd-temp-buffer (&optional name mode)
  "Generate new temporary buffer."
  (interactive "p")
  (let* ((format (concat "*" rcd-temp-buffer-name "%s%s*"))
	 (buffer (if name (format format ": " name) (format format "" "")))
	 (file-name (concat rcd-temp-file-directory (format-time-string "%Y-%m-%d-%H:%M:%S.txt"))))
    (switch-to-buffer (generate-new-buffer buffer))
    (setq buffer-file-name file-name)
    (if current-prefix-arg
	(let* ((mode (completing-read
		      "Mode: "
		      (map-keys rcd-temp-buffer-modes) nil t nil
		      'rcd-temp-buffer-mode-history)))
	  (funcall (intern mode)))
      (funcall (intern (or mode "fundamental-mode"))))))

Now if I have `do-auto-save' those temporary buffers would be saved I guess.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Buffer not visiting file does not know where it should
> be saved.

I've got news for you, because there is a present working
directory, with `pwd'.

C-u M-x pwd RET

/home/incal/News/

:)

PS. In Unix many people think pwd(1) is a shell tool (program)
    written in C - they are right, but what you get with just
    "pwd" in the shell is more often a shell built-in command
    that has higher priority than the tool ... observe:

    $ t pwd # https://dataswamp.org/~incal/conf/.zsh/ide line 74-108
    pwd: shell built-in command
    /bin/pwd
    -rwxr-xr-x 1 root 43K Sep 24  2020 /bin/pwd
    /usr/bin/pwd
    -rwxr-xr-x 1 root 43K Sep 24  2020 /usr/bin/pwd

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

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

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

On 3/15/22 07:47, Jean Louis wrote:
> * hw <hw@adminart.net> [2022-03-15 08:22]:
>> Yes, and how do I make it so that a buffer not visiting a file is
>> being auto-saved without delay once the auto-save-mode has been
>> enabled?  Or can I make it auto-save once before enabling auto-save
>> mode?
> 
> Buffer not visiting file does not know where it should be saved. I am
> using and doing something similar like you, I use buffers without file
> names as additional scratch buffers. If Emacs session is over, those
> temporary buffers are over. And I like sometimes to invoke them in
> different mode, such as `sql-mode' or `emacs-lisp-mode'. Because they
> are not connected to files, they can't be saved so easily.
> 
> (defvar rcd-temp-buffer-mode-history nil)
> (defvar rcd-temp-file-directory "~/tmp/")
> (defvar rcd-temp-buffer-name "RCD TEMPORARY BUFFER")
> (defvar rcd-temp-buffer-modes '(("adoc-mode" . "adoc")
> 				("emacs-lisp-mode" . "el")
> 				("lisp-mode" . ".lisp")
> 				("markdown-mode" . ".md")
> 				("org-mode" . "org")
> 				("sql-mode" . "sql")
> 				("fundamental-mode" . "txt")
> 				("html-mode" . "html")))
> 
> 
> (defun rcd-temp-buffer (&optional name mode)
>    "Generate new temporary buffer."
>    (interactive "p")
>    (let* ((format (concat "*" rcd-temp-buffer-name "%s%s*"))
> 	 (buffer (if name (format format ": " name) (format format "" ""))))
>      (switch-to-buffer (generate-new-buffer buffer))
>      (if current-prefix-arg
> 	(let* ((mode (completing-read
> 		      "Mode: "
> 		      (map-keys rcd-temp-buffer-modes) nil t nil
> 		      'rcd-temp-buffer-mode-history)))
> 	  (funcall (intern mode)))
>        (funcall (intern (or mode "fundamental-mode"))))))
> 
> and that function could be adopted to provide file names for buffers:
> 
> (defun rcd-temp-buffer (&optional name mode)
>    "Generate new temporary buffer."
>    (interactive "p")
>    (let* ((format (concat "*" rcd-temp-buffer-name "%s%s*"))
> 	 (buffer (if name (format format ": " name) (format format "" "")))
> 	 (file-name (concat rcd-temp-file-directory (format-time-string "%Y-%m-%d-%H:%M:%S.txt"))))
>      (switch-to-buffer (generate-new-buffer buffer))
>      (setq buffer-file-name file-name)
>      (if current-prefix-arg
> 	(let* ((mode (completing-read
> 		      "Mode: "
> 		      (map-keys rcd-temp-buffer-modes) nil t nil
> 		      'rcd-temp-buffer-mode-history)))
> 	  (funcall (intern mode)))
>        (funcall (intern (or mode "fundamental-mode"))))))
> 
> Now if I have `do-auto-save' those temporary buffers would be saved I guess.


Thank you very much!

With this, it's not at all necessary to tie the buffers to files. The
do-auto-save function saves "all buffers that need it", and does it
"right now", without delay when called. That's perfect for what I'm
doing.

[-- Attachment #2: tidyperl.el --]
[-- Type: text/x-emacs-lisp, Size: 1154 bytes --]


(defun my-perltidy-replace (arg)
  "Replace the contents of the current buffer with the output of
perltidy, and make a backup of the current buffer.

Before and after modifications to contents of buffers are being
made, all buffers that need to be auto-saved are being
auto-saved.

The major-mode of the buffer containing the backup is set to
cperl-mode."
  (interactive "P")
  (do-auto-save)
  (let ((tidy_buffer (generate-new-buffer (generate-new-buffer-name (concat "TidyBackup-" (buffer-name))))))
    (with-current-buffer (buffer-name)
      ;; swapping the text can screw up linum mode with two buffers in
      ;; the same frame when automatically enabled by cperl-mode
      (linum-mode -1)
      (shell-command-on-region (point-min) (point-max) "perltidy --standard-output" tidy_buffer)
      (buffer-swap-text tidy_buffer))
    (with-current-buffer tidy_buffer
      (auto-save-mode nil)
      (do-auto-save)
      (cperl-mode))
    (linum-mode 1)
    (message "buffer contents replaced with output of perltidy; backup is in %s" tidy_buffer)))

(eval-after-load 'cperl-mode
  '(define-key cperl-mode-map (kbd "C-x t i") 'my-perltidy-replace))

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

> Replace the contents of the current buffer with the output
> of perltidy, and make a backup of the current buffer.
> 
> Before and after modifications to contents of buffers are
> being made, all buffers that need to be auto-saved are being
> auto-saved.
> 
> The major-mode of the buffer containing the backup is set to
> cperl-mode.

Emacs thinks that ...

-  First line is not a complete sentence

-  Argument ‘arg’ should appear (as ARG) in the doc string

-  Lisp symbol ‘cperl-mode’ should appear in quotes

Rats!

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

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Thu, 2022-03-17 at 06:00 +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> hw wrote:
> 
> > Replace the contents of the current buffer with the output
> > of perltidy, and make a backup of the current buffer.
> > 
> > Before and after modifications to contents of buffers are
> > being made, all buffers that need to be auto-saved are being
> > auto-saved.
> > 
> > The major-mode of the buffer containing the backup is set to
> > cperl-mode.
> 
> Emacs thinks that ...
> 
> -  First line is not a complete sentence
> 
> -  Argument ‘arg’ should appear (as ARG) in the doc string
> 
> -  Lisp symbol ‘cperl-mode’ should appear in quotes
> 
> Rats!
> 

Thanks!  I didn't know that emacs can even think, though :)


(defun my-perltidy-replace ()
  "This function replaces the contents of the current buffer with
the output of perltidy, and makes a backup of the current buffer.

Before and after modifications to contents of buffers are being
made, all buffers that need to be auto-saved are being
auto-saved.

The major-mode of the buffer containing the backup is set to
'cperl-mode'."
  (interactive "P")
  (do-auto-save)
  (let ((tidy_buffer (generate-new-buffer (generate-new-buffer-name (concat "TidyBackup-" (buffer-name))))))
    (with-current-buffer (buffer-name)
      ;; swapping the text can screw up linum mode with two buffers in
      ;; the same frame when automatically enabled by cperl-mode
      (linum-mode -1)
      (shell-command-on-region (point-min) (point-max) "perltidy --standard-output" tidy_buffer)
      (buffer-swap-text tidy_buffer))
    (with-current-buffer tidy_buffer
      (auto-save-mode nil)
      (do-auto-save)
      (cperl-mode))
    (linum-mode 1)
    (message "buffer contents replaced with output of perltidy; backup is in %s" tidy_buffer)))

(eval-after-load 'cperl-mode
  '(define-key cperl-mode-map (kbd "C-x t i") 'my-perltidy-replace))

RE: [External] : Re: how to force auto-save of buffers not visiting files, right now?

[Drew Adams]

> > Emacs thinks that ...
> 
> Thanks!  I didn't know that emacs can even think, though :)

Not to worry.  Emacs knows that _we_ can think, and even counts on it!

Re: [External] : Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Fri, 2022-03-18 at 14:45 +0000, Drew Adams wrote:
> > > Emacs thinks that ...
> > 
> > Thanks!  I didn't know that emacs can even think, though :)
> 
> Not to worry.  Emacs knows that _we_ can think, and even counts on it!

In this case, it's kinda true because the adjusted version doesn't work
because the argument is required, so:


(defun my-perltidy-replace (arg)
  "This function replaces the contents of the current buffer with
the output of perltidy, and makes a backup of the current buffer.

Before and after modifications to contents of buffers are being
made, all buffers that need to be auto-saved are being
auto-saved.

The major-mode of the buffer containing the backup is set to
'cperl-mode'.

The argument ARG is unused."
[..]

Re: [External] : Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

>>>> Emacs thinks that ...
>>> 
>>> Thanks! I didn't know that emacs can even think, though :)
>> 
>> Not to worry. Emacs knows that _we_ can think, and even
>> counts on it!
>
> In this case, it's kinda true because the adjusted version
> doesn't work because the argument is required, so:
>
> (defun my-perltidy-replace (arg)
>   "This function replaces the contents of the current buffer with
> the output of perltidy, and makes a backup of the current buffer.
>
> Before and after modifications to contents of buffers are being
> made, all buffers that need to be auto-saved are being
> auto-saved.
>
> The major-mode of the buffer containing the backup is set to
> 'cperl-mode'.
>
> The argument ARG is unused."

In that case, call the argument _ and the docstring comment
can be removed.

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

Re: how to force auto-save of buffers not visiting files, right now?

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Date: Tue, 15 Mar 2022 06:20:41 +0100
> 
> On Mon, 2022-03-14 at 14:48 +0200, Eli Zaretskii wrote:
> > > From: hw <hw@adminart.net>
> > > Date: Mon, 14 Mar 2022 05:55:34 +0100
> > > 
> > > how do I force auto-saving of a particular buffer, or of all buffers,
> > > that are not visiting a file, right now?
> > 
> > "M-x do-auto-save RET"
> > 
> > As for buffers not visiting files: you should set that up separately,
> > e.g. by turning on the auto-save-mode in those buffers (manually or
> > otherwise).
> > 
> 
> Yes, and how do I make it so that a buffer not visiting a file is
> being auto-saved without delay once the auto-save-mode has been
> enabled?  Or can I make it auto-save once before enabling auto-save
> mode?

Not before, _after_.

Re: how to force auto-save of buffers not visiting files, right now?

[Michael Heerdegen]

hw <hw@adminart.net> writes:

> Hi,
>
> how do I force auto-saving of a particular buffer, or of all buffers,
> that are not visiting a file, right now?
>
> I would like to improve below function by auto-saving the backup:

Normally you should be able to `undo' if something went wrong.  Even
when the buffer has no associated file.

Michael.

RE: [External] : Re: how to force auto-save of buffers not visiting files, right now?

[Drew Adams]

> Normally you should be able to `undo' if
> something went wrong.  Even when the buffer
> has no associated file.

Yes.  Yet another reason that buffers such as
*Pp Eval Output*, and even read-only buffers
such as *Messages*, should have undo by default.

Visited buffers are sometimes usefully edited.
We're not gaining much nowadays, I think, by
omitting undo from such buffers by default.

(In `pp+.el' I added undo to *Pp Eval Output*,
at least.)

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Wed, 2022-03-16 at 01:51 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > Hi,
> > 
> > how do I force auto-saving of a particular buffer, or of all buffers,
> > that are not visiting a file, right now?
> > 
> > I would like to improve below function by auto-saving the backup:
> 
> Normally you should be able to `undo' if something went wrong.  Even
> when the buffer has no associated file.

Think it through: You can only undo when nothing goes wrong.  With
copies of buffers being autmatically saved to auto-save files, you
can recover from the auto-save files when something does go wrong.
When nothing goes wrong, these buffers and auto-save files automatically
go away.

Undo can't do that.

Can you save the undo information?  Can you swap the undo information
from one buffer to another just like you can swap buffer contents (with
(buffer-swap-text example_buffer))?

Why is there no undo information saved with auto-save files and none
with save-desktop-mode?

Re: how to force auto-save of buffers not visiting files, right now?

[Michael Heerdegen]

hw <hw@adminart.net> writes:

> Think it through: You can only undo when nothing goes wrong.  With
> copies of buffers being autmatically saved to auto-save files, you
> can recover from the auto-save files when something does go wrong.
> When nothing goes wrong, these buffers and auto-save files automatically
> go away.

What are these "something"s that make undo not work but have no effect
on your auto-saving?  How do you check if "nothing goes wrong" and these
auto-save files can be deleted?

With only abstract "things that go wrong" and claiming auto save files
solve all problems and undo none, without being more specific, I can't
say much more.

If you want files and you feel safe with having them, nothing wrong with
that.

And yes, Emacs could perform better with the information collected by
undo.  "undo-tree.el" is one approach to achieve that.  AFAIR it now
supports also saving undo histories.

In your scenario however I would expect that when "something goes wrong"
you just hit undo and get the former buffer contents, and that's it.

Michael.

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Thu, 2022-03-17 at 23:07 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > Think it through: You can only undo when nothing goes wrong.  With
> > copies of buffers being autmatically saved to auto-save files, you
> > can recover from the auto-save files when something does go wrong.
> > When nothing goes wrong, these buffers and auto-save files automatically
> > go away.
> 
> What are these "something"s that make undo not work but have no effect
> on your auto-saving?  How do you check if "nothing goes wrong" and these
> auto-save files can be deleted?

Perltidy is a code formatter for perl, see [1].  It's not impossible that
perltidy messes up the code, and you might find out only later when testing
the program you're working on, which can be hours or days later, after you
have been programming and been using perltidy lots of times.  Your program
may not always in a state where you could test or even run it at the time
when you want to use perltidy.

When you use perltidy only right before you want to run and test your program,
you still want to have a backup from before you used perltidy so that, if
you need to, can try the version that wasn't altered by perltidy to see if
that makes a difference.  Of course you can save backups manually, but it's
nicer to have that automated.

Swapping buffer contents removes the undo information.  Even if you have all
the undo information, how do you jump between different states of the contents
of the buffer, like to yesterday morning?  Undo goes only step by step, and
you probably do not want to undo hours of programming step by step until you
arrive at yesterday morning, save that state, try to run that version (which
may be unfinished and won't run) and then redo all the steps.

Undo wasn't made for that.  It's great to be able to go back a couple steps,
but not hundreds or thousands.

All kinds of other things can go wrong.  Emacs may crash, your computer may
feeze or crash, your graphics card or your display may fail and leave you
blind, or whatever.  When the version of your program that wasn't altered
by perltidy is lost due to things like that, you won't be able to undo that
when it wasn't saved.

The undo you have in mind only works when nothing goes wrong, and it goes
only so far.

> With only abstract "things that go wrong" and claiming auto save files
> solve all problems and undo none, without being more specific, I can't
> say much more.

I can't possibly list all things that can go wrong.  Maybe you have never
experienced that a computer or software doesn't work as it should or that
things can go wrong.  If you want to find out, you might use wayland with
sway and libreoffice because libreoffice loves to crash all the time then.
Or use thunderbird and try to open attachments --- you'll find that some
of them are garbled because thunderbird is currently buggy, while evolution
lets you open them just fine.  Other things have gone wrong in the past,
and it's not unreasonable to expect that other things or the same ones will
go wrong in the future.

In any case, I never said that auto-save files would solve all problems.

> If you want files and you feel safe with having them, nothing wrong with
> that.
> 
> And yes, Emacs could perform better with the information collected by
> undo.  "undo-tree.el" is one approach to achieve that.  AFAIR it now
> supports also saving undo histories.
> 
> In your scenario however I would expect that when "something goes wrong"
> you just hit undo and get the former buffer contents, and that's it.

Why would you expect that perltidy will never ever damage your source code
so that you do not need to keep a copy of what you used it on?  That would
be unreasonable.

It's enough when you don't like the formatting it produces in some case and
want to undo it.  Without a copy, the undo you have in mind is at best pretty
unwieldy for giving you back what you had before.

My expectation is always that things can go wrong, and I never trust computers.
I do not expect that files saved somewhere will be there and undamaged, only
that they usually are and only because I don't see a better alternative.  A long
time ago I did experience that files got damaged when they were saved, and it
was quite a nightmare and turned out to be due to a broken disc controller.
Another time an xfs file system got damaged and I had to recover from the backup,
and I never really found out why and can only suspect that I used wrong settings
when mounting it.

Just expect things to go wrong; sooner or later they will, always.  Remember the
story about why bugs are called bugs, and that alone kinda tells you all about
things being able to go wrong.

The function I created makes it very easy for me to use perltidy and minimizes
the risk of things going wrong, and it has the side effect of giving me copies,
which can be useful.  If you have a better way, it'd be interesting to hear about
it.  A simple undo doesn't cut it, it only works when nothing goes wrong.

Re: how to force auto-save of buffers not visiting files, right now?

[Michael Heerdegen]

hw <hw@adminart.net> writes:

> When you use perltidy only right before you want to run and test your
> program, you still want to have a backup from before you used perltidy
> so that, if you need to, can try the version that wasn't altered by
> perltidy to see if that makes a difference.  Of course you can save
> backups manually, but it's nicer to have that automated.

But why isn't your code located in a buffer visiting a file?

> I can't possibly list all things that can go wrong.  Maybe you have never
> experienced that a computer or software doesn't work as it should or that
> things can go wrong.  If you want to find out, you might use wayland with
> sway [...]

X crashes often enough, sometimes including the kernel.  That's good
enough for me.

> Why would you expect that perltidy will never ever damage your source code
> so that you do not need to keep a copy of what you used it on?  That would
> be unreasonable.

That's what I don't understand: if it's your source code, why is your
question about "how to force auto-save of buffers not visiting files,
right now?"?

Michael.

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sat, 2022-03-19 at 02:18 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > When you use perltidy only right before you want to run and test your
> > program, you still want to have a backup from before you used perltidy
> > so that, if you need to, can try the version that wasn't altered by
> > perltidy to see if that makes a difference.  Of course you can save
> > backups manually, but it's nicer to have that automated.
> 
> But why isn't your code located in a buffer visiting a file?

It is.  The output of perltidy replaces it.  So I can either manually have
perltidy save the output to a (temporary) file, mark and delete the source
code in the buffer visiting the file, visit the temporary file, mark the
altered source code, copy it, paste it into the buffer visiting the file,
save it and finally delete the temporary file.

That would be quite unwieldy, and I won't have a backup.

I guess I could have perltidy overwrite the file that is being visited.  In
that case, I would have to revert the buffer and the unmodified version is
lost, so I still won't have a backup.  I'm not sure if and how well undo
would work in these cases.  I may be wrong, but I'm assuming there is a limit
to how much undo information is kept.

A simple case like the power going out will destroy all undo information and
the unaltered version of the file.  I have seen (cheap, but APC) UPSs causing
power outages more often than the power went out simply by perferming a self
test, and there is no guarantee that more expensive ones may not have the
same issue.

> > I can't possibly list all things that can go wrong.  Maybe you have never
> > experienced that a computer or software doesn't work as it should or that
> > things can go wrong.  If you want to find out, you might use wayland with
> > sway [...]
> 
> X crashes often enough, sometimes including the kernel.  That's good
> enough for me.
> 

Hm, I haven't had that in a very long time.  It almost never happens.

> > Why would you expect that perltidy will never ever damage your source code
> > so that you do not need to keep a copy of what you used it on?  That would
> > be unreasonable.
> 
> That's what I don't understand: if it's your source code, why is your
> question about "how to force auto-save of buffers not visiting files,
> right now?"?

Because I was trying to find out how to do that.  If you look at the function I
wrote and\or try it out and see what it does, you'll understand.  How would you
do what the function does?

I found some functions like it on the emacs wiki and on github.  I didn't like
the ones on the wiki and was unsure about the one on github.  So I decided to
write my own.

It doesn't even matter if you use perltidy or any other program to alter and
replace the contents of the current buffer, or if you don't alter them at all
(or alter them yourself) and just make transient copies.  Being able to make
transient copies on the fly can be a useful feature in itself.

Re: how to force auto-save of buffers not visiting files, right now?

[Michael Heerdegen]

hw <hw@adminart.net> writes:

> > But why isn't your code located in a buffer visiting a file?
>
> It is.  The output of perltidy replaces it.

Ok - but does it have to be auto-save?  Why not just use normal backup
files?  You can explicitly force the creation of backup files.  And keep
a lot of them around.  See (info "(emacs) Backup") and
(info "(emacs) Backup Deletion").  You can, for example, have hundred
backups of each file you edit - in a folder of your choice so that they
don't clobber your working directories.

If you are familiar with git, I suggest to have a look at Magit and the
wip modes.  After some setup, you get a backup for every save - or even
two, if the original state of the file was not yet backed up.  Due to
git's delta compression it doesn't waste much disk space.  The interface
lets you browse the versions and diff them etc.

"helm-backup.el" does something similar.  You can use more than one
method to gain some protection by redundancy.  The git based approaches
have one big disadvantage though: deleting old versions is not trivial,
you need to mess with git trees (that are not even branches) and
manipulate references "by hand".  Not cool.

I always wanted to implement a similar interface for making backups
using "bup" - which would offer efficient compression of subsequent
versions without the need of registering (tracking) the files, but
didn't start the task yet.  With "bup" you can at least store backups in
different places, it's somewhat easier to handle.  But it also doesn't
allow history manipulation in a simple way.

And then you can make redundant backups of these backups to disk so that
you finally can, without fear, rely on undo :-) In your case, undo
should normally work, and it should be the fastest way to get the
original contents back.

Michael.

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sat, 2022-03-19 at 04:47 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > > But why isn't your code located in a buffer visiting a file?
> > 
> > It is.  The output of perltidy replaces it.
> 
> Ok - but does it have to be auto-save?

No, it doesn't.  It only seemed to be an easy way to achieve what I
wanted.

> Why not just use normal backup files?

Because I would need to delete them eventually, and IIRC, tramp
doesn't necessarily delete them.  Some (remote) directories are not
writable by the user editing the file.

For example, I may edit a file '/usr/local/bin/example.pl' which is
owned by foo:foo because I made that so.  The directory
'/usr/local/bin/' is owned by root.  How do you expect emacs to create
a backup file there?  For remote files, I have set
tramp-auto-save-directory to a local directory, and I'm missing an
equivalent option for local files.

> You can explicitly force the creation of backup files.  And keep
> a lot of them around.

I can't (actually I don't want to, but you get the idea, and then
there is also NFS which would require me to go to lengths to force it,
depending ...) force the creation of backup files in non-writable
directories.

I don't want to keep a lot of backup files around in directories like
'/usr/local/bin/'.  Going through all the overhead of using git when
you have users waiting on you to fix a little problem isn't ideal when
you don't want to turn '/usr/local/bin/' into a git repo.  First fix
the problem so the users can keep working and then bring the git repo
up to date.

> See (info "(emacs) Backup")

Hm I keep forgetting that emacs makes only one backup file only once,
which makes them pretty useless.  And I can't be bothered to configure
emacs on all machines and for all users and keep the configurations up
to date.

Who can remember things like ‘C-u C-u C-u C-x C-s’ just to save a file?

> and (info "(emacs) Backup Deletion").

What happens when I edit the same file directly in instances of emacs
running locally in a session of tmux accessed through ssh and
indirectly in instances of emacs running remotely, visiting the file
through tramp?  Neither the versions of emacs, nor their
configurations are identical.  They are versions like 29.0.50 (Fedora,
wayland version), 24.3.1 (Centos 7), 24.4.1 (a derelict Gentoo
installation), 27.1 (Debian) ...

How do you make sure that all obsolete backup files are being deleted
without configuring about 20 instances of emacs on different machines
for different users?

> You can, for example, have hundred backups of each file you edit -
> in a folder of your choice so that they don't clobber your working
> directories.

I don't want like 20000 backup files all over all the places :)  When
something goes wrong, you're basically guaranteed that either at least
some of them will stick around or relevant ones will be deleted, or
both, in which case you may be left with only the irrelevant ones.
And which ones are the relevant ones?  Can you tell by their numbers?

> If you are familiar with git, I suggest to have a look at Magit and the
> wip modes.

Yes, I need to look into good ways to use git with emacs.

> After some setup, you get a backup for every save - or even
> two, if the original state of the file was not yet backed up.  Due to
> git's delta compression it doesn't waste much disk space.  The interface
> lets you browse the versions and diff them etc.
> 
> "helm-backup.el" does something similar.  You can use more than one
> method to gain some protection by redundancy.  The git based approaches
> have one big disadvantage though: deleting old versions is not trivial,
> you need to mess with git trees (that are not even branches) and
> manipulate references "by hand".  Not cool.

Right, I wouldn't want to have obsolete copies cluttering the repos
for every time I press C-x C-s or C-x s.  I rather commit only the
version that is working after it was modified, not countless
intermediate versions.

Emacs crashed a lot on the Atari ST, and I still automatically hit 'C-x
s' almost as much as I used to.

> I always wanted to implement a similar interface for making backups
> using "bup" - which would offer efficient compression of subsequent
> versions without the need of registering (tracking) the files, but
> didn't start the task yet.  With "bup" you can at least store backups in
> different places, it's somewhat easier to handle.  But it also doesn't
> allow history manipulation in a simple way.

But then you would have to configure all instances of emacs.

> And then you can make redundant backups of these backups to disk so that
> you finally can, without fear, rely on undo :-) In your case, undo
> should normally work, and it should be the fastest way to get the
> original contents back.

Ok so I run perltidy to replace the contents of the buffer visiting
the program I'm working on, save the buffer so I can run the program
and the power goes out, the computer freezes, emacs crashes or
something else goes wrong and it turns out that perltidy messed up my
program.

How do I undo the changes then?  Undo only works when nothing goes
wrong.

Sure, it "normally works" when you ignore that swapping the buffer
contents inevitably removes the undo information, which means it
doesn't work.  Yet "normally" is kinda boring, and backup files and
auto-save files are precisely for when things get interesting and when
we need to be smarter than boring.

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

>> Why not just use normal backup files?
>
> Because I would need to delete them eventually, and IIRC,
> tramp doesn't necessarily delete them.

I personally have

  (setq make-backup-files nil)

but for the record you don't "need" to delete anything and
especially not text or source files.

Use this command:

$ du -hc ~/**/*~ | awk '/total/{print $1}'

To find out how much space your backups really take.

Nothing, right?

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

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

>> Why not just use normal backup files?
>
> Because I would need to delete them eventually, and IIRC,
> tramp doesn't necessarily delete them.

1) No :)

2) And this command is better:

     du -hc ~/**/*~ | tail -1 | cut -f 1

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

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sat, 2022-03-19 at 08:51 +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> hw wrote:
> 
> > > Why not just use normal backup files?
> > 
> > Because I would need to delete them eventually, and IIRC,
> > tramp doesn't necessarily delete them.
> 
> 1) No :)
> 
> 2) And this command is better:
> 
>      du -hc ~/**/*~ | tail -1 | cut -f 1

Better how for what?  I took so long to run that I interrupted it
before it produced any output, after like 20 seconds.

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

>>>> Why not just use normal backup files?
>>> 
>>> Because I would need to delete them eventually, and IIRC,
>>> tramp doesn't necessarily delete them.
>> 
>> 1) No :)
>> 
>> 2) And this command is better:
>> 
>>   du -hc ~/**/*~ | tail -1 | cut -f 1
>
> Better how for what?

The previous greped for total, but that can appear in
filenames, so this use of tail(1) is _much_ better
actually :)

> I took so long to run that I interrupted it before it
> produced any output, after like 20 seconds.

?

But what did you run it on, not your Game Boy right?

Here it runs on 0.13s (0.57s) on zsh (time) and on

  (+ 0.008 0.006 0.003) ; 0.17s

in bash (again 'time', but not the same).


    Timeline? This is no time to talk about time. We don't
    have the time! ...
    
                 -- Cmdr Deanna Troi (First Contact, 1994)

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

Re: how to force auto-save of buffers not visiting files, right now?

[Michael Albinus]

hw <hw@adminart.net> writes:

Hi,

> For example, I may edit a file '/usr/local/bin/example.pl' which is
> owned by foo:foo because I made that so.  The directory
> '/usr/local/bin/' is owned by root.  How do you expect emacs to create
> a backup file there?  For remote files, I have set
> tramp-auto-save-directory to a local directory, and I'm missing an
> equivalent option for local files.

There is the user option auto-save-file-name-transforms, which gives you
this feature also for local files.

Best regards, Michael.

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sat, 2022-03-19 at 10:58 +0100, Michael Albinus wrote:
> hw <hw@adminart.net> writes:
> 
> Hi,
> 
> > For example, I may edit a file '/usr/local/bin/example.pl' which is
> > owned by foo:foo because I made that so.  The directory
> > '/usr/local/bin/' is owned by root.  How do you expect emacs to create
> > a backup file there?  For remote files, I have set
> > tramp-auto-save-directory to a local directory, and I'm missing an
> > equivalent option for local files.
> 
> There is the user option auto-save-file-name-transforms, which gives you
> this feature also for local files.

Thanks!

Its value is
(("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))

Ah, hm, what is that regexp supposed to match?  All files with at
least a ':', a bunch of slashes and some optional brackets?  Who puts
bracktes into file names, that shouldn't be allowed.

Apprently that leads to puttting some files into /tmp, and I would
consider it a bug to put auto-save files into /tmp because doing that
totally defeats the auto-saving because /tmp is volatile.  I don't
know who made the utterly stupid decision to make /tmp volatile, but
it's the way it is since quite a while now.  This default needs to be
changed, or /tmp needs to go back to be a useful directory.

Why didn't they just make a directory /volatile in addition to /tmp?
Because someone would argue that when something must not be saved,
then don't save it to begin with?

But then, the auto-save files for buffers not visiting files show up
in the directories the files are in from which the buffers not
visiting these files were created.

That is very confusing.

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

> Its value is
> (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
>
> Ah, hm, what is that regexp supposed to match?

You must decipher it char by char if you don't understand it.

And keep doing this every time you see one that you want to
understand or use.

Before long, "decipher" ends and "seeing" begins.

Or, as the great late expert of symbolic representation
Yogi Berra once said, you can see a lot just by watching!

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

RE: [External] : Re: how to force auto-save of buffers not visiting files, right now?

[Drew Adams]

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

> Before long, "decipher" ends and "seeing" begins.
> 
> Or, as the great late expert of symbolic representation
> Yogi Berra once said, you can see a lot just by watching!

Wonderful!

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13582 bytes --]

Re: how to force auto-save of buffers not visiting files, right now?

[tomas]

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

On Sun, Mar 20, 2022 at 07:36:42AM +0100, hw wrote:
> On Sat, 2022-03-19 at 10:58 +0100, Michael Albinus wrote:
> > hw <hw@adminart.net> writes:
> > 
> > Hi,
> > 
> > > For example, I may edit a file '/usr/local/bin/example.pl' which is
> > > owned by foo:foo because I made that so.  The directory
> > > '/usr/local/bin/' is owned by root.  How do you expect emacs to create
> > > a backup file there?  For remote files, I have set
> > > tramp-auto-save-directory to a local directory, and I'm missing an
> > > equivalent option for local files.
> > 
> > There is the user option auto-save-file-name-transforms, which gives you
> > this feature also for local files.
> 
> Thanks!
> 
> Its value is
> (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
> 
> Ah, hm, what is that regexp supposed to match?  All files with at
> least a ':', a bunch of slashes and some optional brackets?  Who puts
> bracktes into file names, that shouldn't be allowed.

The colon is to match remote files. That's the default. Tramp remote
files for Emacs have a prefix with a colon.

And the brackets are regexp metacharacters, [^/]* meaning zero or
more non-slashes (i.e. one path component)

Or do you mean the parentheses ()? Those are for grouping. Due to
Emacs's regexp syntax (not ERE) you have to escape them. The extra
backslash is for the string syntax.

> Apprently that leads to puttting some files into /tmp, and I would
> consider it a bug to put auto-save files into /tmp because doing that
> totally defeats the auto-saving because /tmp is volatile.

One person's bugs are other person's features. That's why you can
change it, after all.

I don't know why the default is as it is, but knowing Emacs I guess
there has been some discussion. I'll leave it to you to *POLITELY*
(hint, hint) ask around here if you are interested.

> I don't
> know who made the utterly stupid decision to make /tmp volatile,

Careful. You can change that, too, if you want. Someone thought
it to be useful. I'm around for long enough that I remember the
time before (for Gnu/Linux, anyway). I got along the change. It
has up- and downsides. Throwing "stupid" around won't change those
things :)

> but
> it's the way it is since quite a while now.  This default needs to be
> changed, or /tmp needs to go back to be a useful directory.

That depends on whether you want that auto-save file to persist
across operating system sessions or not. Not everybody agrees with
you (or me) on what a nice behaviour is.

> Why didn't they just make a directory /volatile in addition to /tmp?
> Because someone would argue that when something must not be saved,
> then don't save it to begin with?
> 
> But then, the auto-save files for buffers not visiting files show up
> in the directories the files are in from which the buffers not
> visiting these files were created.

In a way, yes. It's whatever the value of `default-directory' is,
I guess, unless you give it an absolute path.

> That is very confusing.

That's perhaps because there are not many people auto-saving
buffers without an associated file: not many around for testing!

Cheers
-- 
t

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

volatile /tmp [was: how to force auto-save of buffers not visiting files, right now?]

[tomas]

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

On Sun, Mar 20, 2022 at 08:29:55AM +0100, tomas@tuxteam.de wrote:

[...]

> > Apprently that leads to puttting some files into /tmp, and I would
> > consider it a bug to put auto-save files into /tmp because doing that
> > totally defeats the auto-saving because /tmp is volatile.

Note that the convention on Gnu/Linux is to use /var/tmp for things
you want to persist across reboots. So perhaps just changing the
replacement value might make you happy.

Cheers
-- 
t

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

Re: volatile /tmp [was: how to force auto-save of buffers not visiting files, right now?]

[hw]

On Sun, 2022-03-20 at 09:05 +0100, tomas@tuxteam.de wrote:
> On Sun, Mar 20, 2022 at 08:29:55AM +0100, tomas@tuxteam.de wrote:
> 
> [...]
> 
> > > Apprently that leads to puttting some files into /tmp, and I would
> > > consider it a bug to put auto-save files into /tmp because doing that
> > > totally defeats the auto-saving because /tmp is volatile.
> 
> Note that the convention on Gnu/Linux is to use /var/tmp for things
> you want to persist across reboots. So perhaps just changing the
> replacement value might make you happy.

Well, I have set `tramp-auto-save-directory' to a suitable value, so
it doesn't really matter.

Shouldn't GNU Emacs use this GNU convention of using /var/tmp/ when
it's all GNU?

Re: volatile /tmp [was: how to force auto-save of buffers not visiting files, right now?]

[tomas]

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

On Sun, Mar 20, 2022 at 11:36:05AM +0100, hw wrote:
> On Sun, 2022-03-20 at 09:05 +0100, tomas@tuxteam.de wrote:
> > On Sun, Mar 20, 2022 at 08:29:55AM +0100, tomas@tuxteam.de wrote:
> > 
> > [...]
> > 
> > > > Apprently that leads to puttting some files into /tmp, and I would
> > > > consider it a bug to put auto-save files into /tmp because doing that
> > > > totally defeats the auto-saving because /tmp is volatile.
> > 
> > Note that the convention on Gnu/Linux is to use /var/tmp for things
> > you want to persist across reboots. So perhaps just changing the
> > replacement value might make you happy.
> 
> Well, I have set `tramp-auto-save-directory' to a suitable value, so
> it doesn't really matter.
> 
> Shouldn't GNU Emacs use this GNU convention of using /var/tmp/ when
> it's all GNU?

That still depends on whether people want auto-saves to persist
reboots. There doesn't seem to be a majority for it, much less a
consensus.

So either change it for yourself (and document what you did, to
help others in your situation) or start convincing people if you
want that to become a more general default :-)

Cheers
-- 
t

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

Re: volatile /tmp [was: how to force auto-save of buffers not visiting files, right now?]

[hw]

On Sun, 2022-03-20 at 12:13 +0100, tomas@tuxteam.de wrote:
> On Sun, Mar 20, 2022 at 11:36:05AM +0100, hw wrote:
> > On Sun, 2022-03-20 at 09:05 +0100, tomas@tuxteam.de wrote:
> > > On Sun, Mar 20, 2022 at 08:29:55AM +0100, tomas@tuxteam.de wrote:
> > > 
> > > [...]
> > > 
> > > > > Apprently that leads to puttting some files into /tmp, and I would
> > > > > consider it a bug to put auto-save files into /tmp because doing that
> > > > > totally defeats the auto-saving because /tmp is volatile.
> > > 
> > > Note that the convention on Gnu/Linux is to use /var/tmp for things
> > > you want to persist across reboots. So perhaps just changing the
> > > replacement value might make you happy.
> > 
> > Well, I have set `tramp-auto-save-directory' to a suitable value, so
> > it doesn't really matter.
> > 
> > Shouldn't GNU Emacs use this GNU convention of using /var/tmp/ when
> > it's all GNU?
> 
> That still depends on whether people want auto-saves to persist
> reboots. There doesn't seem to be a majority for it, much less a
> consensus.
> 
> So either change it for yourself (and document what you did, to
> help others in your situation) or start convincing people if you
> want that to become a more general default :-)

Nah, it's simply a bug that files which are being stored in order to
recover your work after something went wrong --- and that "something"
includes having to reboot --- are being stored in such a way that
recovery is impossible.  It's a feature that doesn't work right and
thus needs to be fixed.

If people want to configure things so that they are broken, that's up
to them.  Intentionally choosing defaults for software in such a way
that the software isn't safe to use is not sane.

It would be like making guns with safety levers (or how ever they are
called) that shoot you when you use the safety lever for the safeness
it is supposed to provide.  Maybe that works when the majority of
people is insane.  Are we there yet?

Re: volatile /tmp [was: how to force auto-save of buffers not visiting files, right now?]

[tomas]

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

On Mon, Mar 21, 2022 at 04:41:59AM +0100, hw wrote:
> 
> On Sun, 2022-03-20 at 12:13 +0100, tomas@tuxteam.de wrote:

[...]

> > That still depends on whether people want auto-saves to persist
> > reboots [...]

> Nah, it's simply a bug [...]

It seems we aren't making progress on this. Keep your standpoint,
I'll keep mine.

I'm out of this thread

Cheers
-- 
t

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

Re: volatile /tmp [was: how to force auto-save of buffers not visiting files, right now?]

[Michael Albinus]

hw <hw@adminart.net> writes:

Hi,

>> So either change it for yourself (and document what you did, to
>> help others in your situation) or start convincing people if you
>> want that to become a more general default :-)
>
> Nah, it's simply a bug that files which are being stored in order to
> recover your work after something went wrong --- and that "something"
> includes having to reboot --- are being stored in such a way that
> recovery is impossible.  It's a feature that doesn't work right and
> thus needs to be fixed.

There won't be any change if you continue to argue on help-gnu-emacs@gnu.org.
Write a bug report, and be prepared for the discussion.

Take into account, that auto-save-file-name-transforms isn't initialized
using hard-coded "/tmp/". It's default value is rather

--8<---------------cut here---------------start------------->8---
`(("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'"
   ,(concat temporary-file-directory "\\2") t))
--8<---------------cut here---------------end--------------->8---

On MS-Windows, this expands for me to

--8<---------------cut here---------------start------------->8---
'(("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'"
   "c:/Users/albinus/AppData/Local/Temp/\\2" t))
--8<---------------cut here---------------end--------------->8---

And if you start Emacs with any value for environment variable $TMP, like

--8<---------------cut here---------------start------------->8---
env TMP=/var/tmp emacs -Q
--8<---------------cut here---------------end--------------->8---

then auto-save-file-name-transforms expands accordingly:

--8<---------------cut here---------------start------------->8---
'(("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/var/tmp/\\2" t))
--8<---------------cut here---------------end--------------->8---

And there is tramp-auto-save-directory, which overrules the said
setting.

Honestly, I don't see a reason to change the current behavior. People
who want that auto-saved remote files exist after a reboot can change
the behavior easily. But many people, including me, don't want this feature.

(I might be biased as Tramp maintainer. Who knows.)

Best regards, Michael.

Re: how to force auto-save of buffers not visiting files, right now?

[Michael Albinus]

<tomas@tuxteam.de> writes:

>> Its value is
>> (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
>>
>> Ah, hm, what is that regexp supposed to match?  All files with at
>> least a ':', a bunch of slashes and some optional brackets?  Who puts
>> bracktes into file names, that shouldn't be allowed.
>
> The colon is to match remote files. That's the default. Tramp remote
> files for Emacs have a prefix with a colon.

Almost, unless you change the Tramp syntax. But that's uncommon these
days, and it might happen for XEmacs converts only.

JFTR.

> Cheers

Best regards, Michael.

Re: how to force auto-save of buffers not visiting files, right now?

[tomas]

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

On Sun, Mar 20, 2022 at 10:57:06AM +0100, Michael Albinus wrote:
> <tomas@tuxteam.de> writes:


> > [...]  Tramp remote files for Emacs have a prefix with a colon.
> 
> Almost, unless you change the Tramp syntax. But that's uncommon these
> days, and it might happen for XEmacs converts only.

I wouldn't even dare to think of it ;-)

But yes, thanks for the heads-up.

And while I'm at it, I was too sloppy: I mumbled something about
prefixes with a colon. It's "prefixes starting with a slash and
containing a colon". Otherwise they might conflict with DOSsy
and Windwossy paths.

Cheers
-- 
t

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

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sun, 2022-03-20 at 08:29 +0100, tomas@tuxteam.de wrote:
> On Sun, Mar 20, 2022 at 07:36:42AM +0100, hw wrote:
> > On Sat, 2022-03-19 at 10:58 +0100, Michael Albinus wrote:
> > > hw <hw@adminart.net> writes:
> > > 
> > > Hi,
> > > 
> > > > For example, I may edit a file '/usr/local/bin/example.pl' which is
> > > > owned by foo:foo because I made that so.  The directory
> > > > '/usr/local/bin/' is owned by root.  How do you expect emacs to create
> > > > a backup file there?  For remote files, I have set
> > > > tramp-auto-save-directory to a local directory, and I'm missing an
> > > > equivalent option for local files.
> > > 
> > > There is the user option auto-save-file-name-transforms, which gives you
> > > this feature also for local files.
> > 
> > Thanks!
> > 
> > Its value is
> > (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
> > 
> > Ah, hm, what is that regexp supposed to match?  All files with at
> > least a ':', a bunch of slashes and some optional brackets?  Who puts
> > bracktes into file names, that shouldn't be allowed.
> 
> The colon is to match remote files. That's the default. Tramp remote
> files for Emacs have a prefix with a colon.
> 
> And the brackets are regexp metacharacters, [^/]* meaning zero or
> more non-slashes (i.e. one path component)
> 
> Or do you mean the parentheses ()? Those are for grouping. Due to
> Emacs's regexp syntax (not ERE) you have to escape them. The extra
> backslash is for the string syntax.

Yes --- I didn't see that because that expression is so unreadable.

Forcing remote auto-save files into being saved into a volatile
directory is worse than not saving them at all.

> > Apprently that leads to puttting some files into /tmp, and I would
> > consider it a bug to put auto-save files into /tmp because doing that
> > totally defeats the auto-saving because /tmp is volatile.
> 
> One person's bugs are other person's features. That's why you can
> change it, after all.

How do I change that /tmp to not being volatile and keep it that way?

> I don't know why the default is as it is, but knowing Emacs I guess
> there has been some discussion. I'll leave it to you to *POLITELY*
> (hint, hint) ask around here if you are interested.

Or it has been decided some time ago when /tmp wasn't volatile and
wasn't changed.

> > I don't
> > know who made the utterly stupid decision to make /tmp volatile,
> 
> Careful. You can change that, too, if you want. Someone thought
> it to be useful.

Like how?

> I'm around for long enough that I remember the
> time before (for Gnu/Linux, anyway). I got along the change. It
> has up- and downsides. Throwing "stupid" around won't change those
> things :)

Some things, like making /tmp volatile, are still stupid.  I
understand and somewhat appreciate that it can be useful to use a
RAM-disk for some temporary files, yet that doesn't mean that breaking
things for everyone would be useful or a good idea.  IIUC, the purpose
of making /tmp volatile wasn't even making it volatile but making
things faster, so whoever did that could and should have introduced an
additional directory for this purpose.  Over time, software could and
probably would have adapted to use either the new directory or not.

For users, it would have been an easy choice to make because they
could simply symlink /tmp to /volatile (or to whatever that new
directory would be called), or the other way round.  It would also
been an option to decide between not keeping and keeping temporary
files.

But no, it was just forced upon us with no choice, and we weren't even
told about such an important change.  I'm sure that some people did
loose their data because of it.  Someone who is in the position to
make important decisions like this needs make better decisions, not
stupid ones like this ones.

> > but
> > it's the way it is since quite a while now.  This default needs to be
> > changed, or /tmp needs to go back to be a useful directory.
> 
> That depends on whether you want that auto-save file to persist
> across operating system sessions or not. Not everybody agrees with
> you (or me) on what a nice behaviour is.

That not everyone agrees with everything doesn't mean that deciding
and thus breaking things for everyone would be a good idea, especially
not when better alternatives are available which accomodate everyone
or at least a lot more people than otherwise.

> > Why didn't they just make a directory /volatile in addition to /tmp?
> > Because someone would argue that when something must not be saved,
> > then don't save it to begin with?
> > 
> > But then, the auto-save files for buffers not visiting files show up
> > in the directories the files are in from which the buffers not
> > visiting these files were created.
> 
> In a way, yes. It's whatever the value of `default-directory' is,
> I guess, unless you give it an absolute path.

Well, why is above regexp apparently ignoring the value of
`default-directory'?  Its description doesn't really describe it in
that it doesn't say what it is being used for.

So what is it being used for?  It's even global and defined in C
source code and buffer-local as well.  Shouldn't it be used to (help)
decide what the default-directory for auto-save files is?

What happens when I change it from it's global value of nil to some
directory?  Why is it nil while the docstring says it should be "an
absolute directory name"?

> > That is very confusing.
> 
> That's perhaps because there are not many people auto-saving
> buffers without an associated file: not many around for testing!

No, that a regexp like that is confusing doesn't have anything to do
with how many people are auto-saving buffers not visiting files.

Besides, IIUC, auto-save-mode is enabled by default for pretty much
every buffer, so everone who changes the contents of buffers, visiting
files or not, is subject to have their buffers auto-saved eventually
unless they change the default.  That's probably a lot of people.

Re: how to force auto-save of buffers not visiting files, right now?

[tomas]

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

On Sun, Mar 20, 2022 at 11:19:52AM +0100, hw wrote:
> 
> On Sun, 2022-03-20 at 08:29 +0100, tomas@tuxteam.de wrote:
> > On Sun, Mar 20, 2022 at 07:36:42AM +0100, hw wrote:

[...]

> > > Its value is
> > > (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))

[...]

> Yes --- I didn't see that because that expression is so unreadable.

To some it is readable, to some not. It takes some practice.

> Forcing remote auto-save files into being saved into a volatile
> directory is worse than not saving them at all.

Are you always so absolute in your assessments?

> How do I change that /tmp to not being volatile and keep it that way?

Look into the files in /etc/init.d (or, if you are a systemd person,
ask around in your distribution's mailing list: I know very little
about systemd). Typically, there's code there to wipe /tmp clean
on boot. Then, you'll have to make sure /tmp is not mounted from
tmpfs (as is customary these days) but from a regular directory.

> > Careful. You can change that, too, if you want. Someone thought
> > it to be useful.
> 
> Like how?

See above. Try

  find /etc/init.d -type f -exec egrep "\<tmp\>" {} +

or ask around if you're on systemd (i guess it'll have one unit
to mount tmpfs on /tmp, perhaps another to clean up /tmp --
unless they rely on always using tmpfs, where the latter would
be unnecessary. But don't believe me on things systemd. Actually
I've no clue :)

> > I'm around for long enough that I remember the
> > time before [...]

> Some things, like making /tmp volatile, are still stupid.

OK, I think I'll stop here. We are off-topic anyway.

Cheers
-- 
t

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

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sun, 2022-03-20 at 11:30 +0100, tomas@tuxteam.de wrote:
> On Sun, Mar 20, 2022 at 11:19:52AM +0100, hw wrote:
> > 
> > On Sun, 2022-03-20 at 08:29 +0100, tomas@tuxteam.de wrote:
> > > On Sun, Mar 20, 2022 at 07:36:42AM +0100, hw wrote:
> 
> [...]
> 
> > > > Its value is
> > > > (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
> 
> [...]
> 
> > Yes --- I didn't see that because that expression is so unreadable.
> 
> To some it is readable, to some not. It takes some practice.

I'm sure there are 5 people for whom it's easily readable.  For others,
it would be helpful if the description would explain what the default
is supposed to match and if it would have same useful examples.

> > Forcing remote auto-save files into being saved into a volatile
> > directory is worse than not saving them at all.
> 
> Are you always so absolute in your assessments?

I am always am what I am.

> > How do I change that /tmp to not being volatile and keep it that way?
> 
> Look into the files in /etc/init.d (or, if you are a systemd person,
> ask around in your distribution's mailing list: I know very little
> about systemd). Typically, there's code there to wipe /tmp clean
> on boot. Then, you'll have to make sure /tmp is not mounted from
> tmpfs (as is customary these days) but from a regular directory.
> 
> > > Careful. You can change that, too, if you want. Someone thought
> > > it to be useful.
> > 
> > Like how?
> 
> See above. Try
> 
>   find /etc/init.d -type f -exec egrep "\<tmp\>" {} +
> 
> or ask around if you're on systemd (i guess it'll have one unit
> to mount tmpfs on /tmp, perhaps another to clean up /tmp --
> unless they rely on always using tmpfs, where the latter would
> be unnecessary. But don't believe me on things systemd. Actually
> I've no clue :)

See, that's one problem, and there are others, like keeping things
changed the way you changed them.  Who says that when you make /tmp
persistent, that the change will persist over the next software or
distribution update or upgrade?  When you start changing things like
that, there are likely to be more and more things over time and it
will be difficult or impossible to maintain that.

So don't say "you can change it".  You can't, really.

> > > I'm around for long enough that I remember the
> > > time before [...]
> 
> > Some things, like making /tmp volatile, are still stupid.
> 
> OK, I think I'll stop here. We are off-topic anyway.

Hm, quite a bit, yes.

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

>> > > > (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
>> 
>> [...]
>> 
>> > Yes --- I didn't see that because that expression is so unreadable.
>> 
>> To some it is readable, to some not. It takes some practice.
>
> I'm sure there are 5 people for whom it's easily readable.  For others,
> it would be helpful if the description would explain what the default
> is supposed to match and if it would have same useful examples.

If you don't know it, easier examples first, yet.

But there is no need for explanations as you call, rather
a syntax list what it means. You don't need more than that,
just look up everything you don't understand until you don't
have to because your brain has it memorized.

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

Re: how to force auto-save of buffers not visiting files, right now?

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Date: Mon, 21 Mar 2022 04:55:22 +0100
> 
> > > > > Its value is
> > > > > (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
> > 
> > [...]
> > 
> > > Yes --- I didn't see that because that expression is so unreadable.
> > 
> > To some it is readable, to some not. It takes some practice.
> 
> I'm sure there are 5 people for whom it's easily readable.  For others,
> it would be helpful if the description would explain what the default
> is supposed to match and if it would have same useful examples.

The doc string already does that:

  The default value is set up to put the auto-save file into the
  temporary directory (see the variable ‘temporary-file-directory’) for
  editing a remote file.

I think this is pretty easy to understand, don't you agree?

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Mon, 2022-03-21 at 14:22 +0200, Eli Zaretskii wrote:
> > From: hw <hw@adminart.net>
> > Date: Mon, 21 Mar 2022 04:55:22 +0100
> > 
> > > > > > Its value is
> > > > > > (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
> > > 
> > > [...]
> > > 
> > > > Yes --- I didn't see that because that expression is so unreadable.
> > > 
> > > To some it is readable, to some not. It takes some practice.
> > 
> > I'm sure there are 5 people for whom it's easily readable.  For others,
> > it would be helpful if the description would explain what the default
> > is supposed to match and if it would have same useful examples.
> 
> The doc string already does that:
> 
>   The default value is set up to put the auto-save file into the
>   temporary directory (see the variable ‘temporary-file-directory’) for
>   editing a remote file.
> 
> I think this is pretty easy to understand, don't you agree?

There must be something wrong with the documentation then.  The
auto-save files are being put into the directories their files are in,
and I didn't change the default.

Re: how to force auto-save of buffers not visiting files, right now?

[Michael Albinus]

hw <hw@adminart.net> writes:

>> The doc string already does that:
>> 
>>   The default value is set up to put the auto-save file into the
>>   temporary directory (see the variable ‘temporary-file-directory’) for
>>   editing a remote file.
>> 
>> I think this is pretty easy to understand, don't you agree?
>
> There must be something wrong with the documentation then.  The
> auto-save files are being put into the directories their files are in,
> and I didn't change the default.

Please read carefully. The doc string says "... for editing remote
files". Local files are not affected by this setting.

Best regards, Michael.

Re: how to force auto-save of buffers not visiting files, right now?

[Michael Heerdegen]

hw <hw@adminart.net> writes:

> For example, I may edit a file '/usr/local/bin/example.pl' which is
> owned by foo:foo because I made that so.  The directory
> '/usr/local/bin/' is owned by root.  How do you expect emacs to create
> a backup file there?  For remote files, I have set
> tramp-auto-save-directory to a local directory, and I'm missing an
> equivalent option for local files.

I'm was talking about backup files, not about auto save.  You can
control where these are saved.

> Who can remember things like ‘C-u C-u C-u C-x C-s’ just to save a
> file?

If you want to use that stuff automatically, you can do it otherwise,
you already wrote some Elisp code.  It's surely not my advice to always
save using that keystroke.

> How do you make sure that all obsolete backup files are being deleted
> without configuring about 20 instances of emacs on different machines
> for different users?

You could, for example, use directory local variables and configure
things so that all backups are located at one centralized place.

> Right, I wouldn't want to have obsolete copies cluttering the repos
> for every time I press C-x C-s or C-x s.  I rather commit only the
> version that is working after it was modified, not countless
> intermediate versions.

With Magit or helm-browse, these saves would not be commits or parts of
named branches.  They would live under a configurable separate namespace
in e.g. ".git/refs/wip/".

> Ok so I run perltidy to replace the contents of the buffer visiting
> the program I'm working on, save the buffer so I can run the program
> and the power goes out, the computer freezes, emacs crashes or
> something else goes wrong and it turns out that perltidy messed up my
> program.
>
> How do I undo the changes then?  Undo only works when nothing goes
> wrong.

My advice was to use undo when nothing went wrong, and your backup
concept when something went wrong.  Sorry if I wasn't clear enough in
that regard.

What kind of solution d you want to have?  I find some of your answers
contradicting, e.g. you say you don't want lots of backups because you
don't want to delete them manually.  But automatic deletion is also not
good because, what if the relevant backup was among the deleted files.
You do not want to loose anything but OTOH do not want to clobber your
repository, etc.

How could a solution you _do_ like look like?

Michael.

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Michael Heerdegen wrote:

>> For example, I may edit a file '/usr/local/bin/example.pl'
>> which is owned by foo:foo because I made that so.
>> The directory '/usr/local/bin/' is owned by root. How do
>> you expect emacs to create a backup file there? For remote
>> files, I have set tramp-auto-save-directory to a local
>> directory, and I'm missing an equivalent option for
>> local files.
>
> I'm was talking about backup files, not about auto save.
> You can control where these are saved.

auto-save, `temporary-file-directory' ?
backup, `backup-directory-alist' ?

Never used any actively so don't know for sure ...

You can obviously "control" both/any/all in Emacs :)

> What kind of solution d you want to have? I find some of
> your answers contradicting, e.g. you say you don't want lots
> of backups because you don't want to delete them manually.
> But automatic deletion is also not good because ...

1. Keep files small.

X. Backup files don't take any disk space in any order
   of significance.

2. Backups should be set up to be kept out of the way
   automatically - or "not selected for the ACTUAL way when
   push comes to shove" - or ... well, whatever, only this
   should just work and be automated, so spend time to get it
   right OR be happy to live on the edge with no backups.
   Because there's no WAY in between!

... uhm, what's the right answer again?

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

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sun, 2022-03-20 at 01:21 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > For example, I may edit a file '/usr/local/bin/example.pl' which is
> > owned by foo:foo because I made that so.  The directory
> > '/usr/local/bin/' is owned by root.  How do you expect emacs to create
> > a backup file there?  For remote files, I have set
> > tramp-auto-save-directory to a local directory, and I'm missing an
> > equivalent option for local files.
> 
> I'm was talking about backup files, not about auto save.  You can
> control where these are saved.

Are you tring to say that I should configure making backup files in
some directory I like to use for them, configure things so that every
time I save a file, yet another backup file is being made, and then I
should use perltidy only after saving so that finally, I have to
delete all the backup files once I figured out which ones I don't need
any longer?

> > Who can remember things like ‘C-u C-u C-u C-x C-s’ just to save a
> > file?
> 
> If you want to use that stuff automatically, you can do it otherwise,
> you already wrote some Elisp code.  It's surely not my advice to always
> save using that keystroke.

I tend to go with default key bindings.  If I don't do that, I would
have to configure all the key bindings I might use and whatever is
needed to make them work everywhere for whatever program I make key
bindings for, and that isn't feasible.  Or I would be screwed because
I don't even know how to quit a program because I don't know which key
to press.  Even the key bindings of emacs are not the same depending
on what kind of display you're using, i. e. a GUI frame or a console
frame.  Even if I configured all that, I might end up stuck in vi
because I overlooked that some user hasn't configured their EDITOR
environment variable to emacs but to vi (which tends to be a default
with Redhat) and hasn't configured vi to use the key bindings I'm used
to.

> > How do you make sure that all obsolete backup files are being deleted
> > without configuring about 20 instances of emacs on different machines
> > for different users?
> 
> You could, for example, use directory local variables and configure
> things so that all backups are located at one centralized place.

Then what do you suggest that I do when the connection to this central
place is down, or the server that serves that place is down? Why would
I care to painstakingly create a single point of failure?  And who is
going to configure all that?

> > Right, I wouldn't want to have obsolete copies cluttering the repos
> > for every time I press C-x C-s or C-x s.  I rather commit only the
> > version that is working after it was modified, not countless
> > intermediate versions.
> 
> With Magit or helm-browse, these saves would not be commits or parts of
> named branches.  They would live under a configurable separate namespace
> in e.g. ".git/refs/wip/".

That might be a nice feature.  I don't know Magit, helm-browse and git
well enough to say anything about this.

> > Ok so I run perltidy to replace the contents of the buffer visiting
> > the program I'm working on, save the buffer so I can run the program
> > and the power goes out, the computer freezes, emacs crashes or
> > something else goes wrong and it turns out that perltidy messed up my
> > program.
> > 
> > How do I undo the changes then?  Undo only works when nothing goes
> > wrong.
> 
> My advice was to use undo when nothing went wrong, and your backup
> concept when something went wrong.  Sorry if I wasn't clear enough in
> that regard.

Oh, ok, I don't have a backup concept I could use for that.  I haven't
really needed one for this because I haven't replaced the contents of
a buffer like this before, and undo plus auto-save files plus saving
the file(s) I'm workig on plus regular backups of everything has been
working well enough so far.

And fortunately, emacs never crashes :)

> What kind of solution d you want to have?  I find some of your answers
> contradicting, e.g. you say you don't want lots of backups because you
> don't want to delete them manually.  But automatic deletion is also not
> good because, what if the relevant backup was among the deleted files.
> You do not want to loose anything but OTOH do not want to clobber your
> repository, etc.

What's contradictory about that?

I'm making backups I don't need to delete unless something went (very)
wrong.  The automatic deletion isn't going to delete anything I would
want to keep (even when and especially if something goes wrong).  I'm
also not clobbering my repository.  With a couple lines of elisp,
emacs is doing it for me in a side effect of what emacs is making
easier for me to do.

There are disadvantages, like when things go bad, I'll have to delete
a bunch of auto-save files; the undo information is being removed from
the buffer by swapping buffer contents (which can be an advantage),
not all the modes are being copied from the original buffer to the
buffer holding the copy (doesn't matter in this case), and the
bookmarks are invalidated (which kinda sucks).  I can live with those,
and maybe some of them can be fixed.

> How could a solution you _do_ like look like?

I like this one:


(defun my-perltidy-replace (_)
  "This function replaces the contents of the current buffer with
the output of perltidy, and makes a backup of the current buffer.

Before and after modifications to contents of buffers are being
made, all buffers that need to be auto-saved are being
auto-saved.

The major-mode of the buffer containing the backup is set to
'cperl-mode'."
  (interactive "P")
  (do-auto-save)
  (let ((tidy_buffer (generate-new-buffer (generate-new-buffer-name (concat "TidyBackup-" (buffer-name))))))
    (with-current-buffer (buffer-name)
      ;; swapping the text can screw up linum mode with two buffers in
      ;; the same frame when automatically enabled by cperl-mode
      (linum-mode -1)
      (shell-command-on-region (point-min) (point-max) "perltidy --standard-output" tidy_buffer)
      (buffer-swap-text tidy_buffer))
    (with-current-buffer tidy_buffer
      (auto-save-mode nil)
      (do-auto-save)
      (cperl-mode))
    (linum-mode 1)
    (message "buffer contents replaced with output of perltidy; backup is in %s" tidy_buffer)))


And for the record:


(defun my-transient-copy (_)
  "This function makes a copy of the current buffer to a new
buffer.  The new buffer does not visit a file.  Its name is based
on the name of the current buffer.

The 'auto-save-mode' is enabled for the new buffer, and all
buffers that need to be auto-saved are being auto-saved right
away, once before the copy is created and once after."
  (interactive "P")
  (do-auto-save)
  (let ((transient_buffer (generate-new-buffer-name (concat "transient-copy-of-" (buffer-name)))))
    (copy-to-buffer transient_buffer (point-min) (point-max))
    (with-current-buffer transient_buffer (auto-save-mode nil))
    (do-auto-save)
    (message "transient copy created as %s" transient_buffer)))

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

> (defun my-perltidy-replace (_)
>   "This function replaces the contents of the current buffer with
> the output of perltidy, and makes a backup of the current buffer.
>
> Before and after modifications to contents of buffers are being
> made, all buffers that need to be auto-saved are being
> auto-saved.
>
> The major-mode of the buffer containing the backup is set to
> 'cperl-mode'."

Emacs thinks

  the second line should not have indentation ...
  
  the first line is not a complete sentence ....
  
  and probably "replaces" should be imperative "replace"!

>       (linum-mode -1)

This is the only one needed.

>       (auto-save-mode nil)

Yuk, not needed ...

BTW final args that could be nil (nil is in the
function range) could always be optional and default to
nil, right?

Here tho it is ugly by all means but also unnecessary since it
_is_ an optional argument, so all good.

>     (linum-mode 1)

Not as ugly! But as equally unnecessary still pretty ugl-
I mean unnecessary.

> (defun my-transient-copy (_)
>   "This function makes a copy of the current buffer to a new
> buffer.  The new buffer does not visit a file.  Its name is based
> on the name of the current buffer.
>
> The 'auto-save-mode' is enabled for the new buffer, and all
> buffers that need to be auto-saved are being auto-saved right
> away, once before the copy is created and once after."

Emacs thinks

Second line should not have indentation

First line is not a complete sentence

Probably "makes" should be imperative "make"

>   (interactive "P")

Interesting, does that work and what does it do?!

>   (do-auto-save)
>   (let ((transient_buffer (generate-new-buffer-name (concat "transient-copy-of-" (buffer-name)))))
>     (copy-to-buffer transient_buffer (point-min) (point-max))

Here is another example - when the last two args a and b and

  (<= (point-min) a b (point-max))

then both formal parameters can be made optional if we had
argument a defaulting to (point-min) and argument b defaulting
to (point-max), right?

>     (with-current-buffer transient_buffer (auto-save-mode
>     nil))

Same.

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

Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sun, 2022-03-20 at 09:08 +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> hw wrote:
> 
> > (defun my-perltidy-replace (_)
> >   "This function replaces the contents of the current buffer with
> > the output of perltidy, and makes a backup of the current buffer.
> > 
> > Before and after modifications to contents of buffers are being
> > made, all buffers that need to be auto-saved are being
> > auto-saved.
> > 
> > The major-mode of the buffer containing the backup is set to
> > 'cperl-mode'."
> 
> Emacs thinks
> 
>   the second line should not have indentation ...

Maybe it was altered during transfer?  It isn't indented.

>   the first line is not a complete sentence ....

To me, it's a complete sentence.  We'd have to ask some people who are
native speakers of English.

>   and probably "replaces" should be imperative "replace"!

Huh?  The function /does/ replace the contents.  It "shalln't" replace
them, if there is even such a word.

> >       (linum-mode -1)
> 
> This is the only one needed.

The wayland version of emacs screws up the display of the line numbers
when you have two buffers displayed in the same frame besides each
other, at least when you're using sway.  Disabling the mode and
re-enabling it is a workaround.

> 
> >       (auto-save-mode nil)
> 
> Yuk, not needed ...

That depends on whether you have auto-save-mode enabled by default or
not ...  In a function, you can either check whether auto-save-mode is
already enabled or not and enable it if it isn't, or just enable it.
In any case, it needs to be enabled for the function to do what I want
it to do, so enable it.

> BTW final args that could be nil (nil is in the
> function range) could always be optional and default to
> nil, right?
> 
> Here tho it is ugly by all means but also unnecessary since it
> _is_ an optional argument, so all good.

What do you mean?  Not all arguments default to nil, may they be
optional or not.

> >     (linum-mode 1)
> 
> Not as ugly! But as equally unnecessary still pretty ugl-
> I mean unnecessary.

When programming, I follow the principle that it's better to be more
explicit when it serves to make it more clear what the intention is.
And I picked '1' as argument rather than 'nil' because it's confusing
that something should be enabled rather disabled because the
equivalent of FALSE is given as an argument to it.  'Nil' should
disable stuff, not enable it.

Please think about this example:

perl -e 'print "no\n" unless false;'

That appears to work, but it leaves you to guess what the intention
is.  Using just (linum-mode) leaves me to guess and seems confusing.

As to optional arguments, I think they are more a disadvantage than an
advantage because the programmers have to make sure not to miss
specifying all arguments correctly every time they want to use a
function.  I rather have it that the computer checks the arguments for
me and tells me when there are missing ones, or too many.  In perl,
you can have that.

I also gave up statements like

array[iterator++] = 'foo';

in favour of either

array[iterator] = 'foo';
iterator++;

or

iterator++;
array[iterator] = 'foo';

a long time ago because they are unclear and cost a lot of time when
reading the code and thus are a nuisance.  If they're prettier, pretty
doesn't always win.

> > (defun my-transient-copy (_)
> >   "This function makes a copy of the current buffer to a new
> > buffer.  The new buffer does not visit a file.  Its name is based
> > on the name of the current buffer.
> > 
> > The 'auto-save-mode' is enabled for the new buffer, and all
> > buffers that need to be auto-saved are being auto-saved right
> > away, once before the copy is created and once after."
> 
> Emacs thinks
> 
> Second line should not have indentation
> 
> First line is not a complete sentence
> 
> Probably "makes" should be imperative "make"
> 
> >   (interactive "P")
> 
> Interesting, does that work and what does it do?!

The function works, yes.  Its description tells you what it does.

> >   (do-auto-save)
> >   (let ((transient_buffer (generate-new-buffer-name (concat "transient-copy-of-" (buffer-name)))))
> >     (copy-to-buffer transient_buffer (point-min) (point-max))
> 
> Here is another example - when the last two args a and b and
> 
>   (<= (point-min) a b (point-max))
> 
> then both formal parameters can be made optional if we had
> argument a defaulting to (point-min) and argument b defaulting
> to (point-max), right?

You're proving my point with this example:

With (copy-to-buffer buffer), you copy the region when omitting the
arguments.  Maybe it's prettier, but it isn't what I wanted.  Maybe
that's why the description tells you not to omit the arguments.

> >     (with-current-buffer transient_buffer (auto-save-mode
> >     nil))
> 
> Same.

Yes, explicitly :)

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

>> Emacs thinks
>> 
>>   the second line should not have indentation ...
>
> Maybe it was altered during transfer? It isn't indented.
>
>>   the first line is not a complete sentence ....
>
> To me, it's a complete sentence. We'd have to ask some
> people who are native speakers of English.
>
>>   and probably "replaces" should be imperative "replace"!
>
> Huh? The function /does/ replace the contents. It "shalln't"
> replace them, if there is even such a word.

Well, it's what Emacs thinks anyway. Run these commands to
find out for yourself ... Doing this before you post code here
is appreciated, as is byte-compiling (and fixing the
errors/warnings) since that is ... beneficial.

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/ide/pack-style.el

(require 'checkdoc)

(setq checkdoc-arguments-in-order-flag       t)
(setq checkdoc-permit-comma-termination-flag t)

(defun check-package-style ()
  (interactive)
  (let ((msg "Style check..."))
    (message msg)
    (checkdoc-current-buffer t) ; TAKE-NOTES
    (message "%sdone" msg) ))
(defalias 'check-style #'check-package-style)

>>> (linum-mode -1)
>> 
>> This is the only one needed.
>
> The wayland version of emacs screws up the display of the
> line numbers when you have two buffers displayed in the same
> frame besides each other, at least when you're using sway.
> Disabling the mode and re-enabling it is a workaround.

I mean the hard-coded disable case is the only one where you
need an argument to the minor mode function ...

>>>       (auto-save-mode nil)
>> 
>> Yuk, not needed ...
>
> That depends on whether you have auto-save-mode enabled by
> default or not ... In a function, you can either check
> whether auto-save-mode is already enabled or not and enable
> it if it isn't, or just enable it. In any case, it needs to
> be enabled for the function to do what I want it to do, so
> enable it.

(auto-save-mode) will also enable.

>> BTW final args that could be nil (nil is in the function
>> range) could always be optional and default to nil, right?
>> 
>> Here tho it is ugly by all means but also unnecessary since
>> it _is_ an optional argument, so all good.
>
> What do you mean? Not all arguments default to nil, may they
> be optional or not.

If the last argument can default to nil and that is sensible
and done, then it can be made optional as well with nothing
lost and with the gains on cleaner code and less typing.

>>> (linum-mode 1)
>> 
>> Not as ugly! But as equally unnecessary still pretty ugl-
>> I mean unnecessary.
>
> When programming, I follow the principle that it's better to
> be more explicit

If you share such code people will get confused and wonder if
it means something else as the other way around is the
conventional/prefered method.

>>> (interactive "P")
>> 
>> Interesting, does that work and what does it do?!
>
> The function works, yes. Its description tells you what
> it does.

What does (interactive "P") in the context of an
anonymous/unemployed argument?

> With (copy-to-buffer buffer), you copy the region when
> omitting the arguments. Maybe it's prettier, but it isn't
> what I wanted. Maybe that's why the description tells you
> not to omit the arguments.

To use the region on interactive use is called a DWIM function
("do what I mean") and in such cases the last two arguments,
BEG and END, could be optional with (point-min) and
(point-max) as defaults. See:

  https://dataswamp.org/~incal/emacs-init/dwim.el

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

Re: how to force auto-save of buffers not visiting files, right now?

[Emanuel Berg via Users list for the GNU Emacs text editor]

hw wrote:

>>> (with-current-buffer transient_buffer (auto-save-mode nil))
>>> 
>> 
>> Same.
>
> Yes, explicitly :)

This makes even less sense actually. It doesn't make sense in
the sense I already mentioned, but it also doesn't make sense
in the sense that intuitively, that looks like you are
_disabling_ the mode! When in fact you are enabling it.

I don't know the reason for this counter-intuitive use of nil,
but if I'm allowed to theorize it is a side-effect of making
the argument, ARG, optional and having

  (auto-save-mode) 

enabling the mode (this is so for all minor modes and is
intuitive), however technically that implies ARG being nil so
for that to happen it must happen when ARG is nil.

If this is indeed the reason I consider explicit use of nil to
enable a mode not just poor style but a bug.

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

Re: how to force auto-save of buffers not visiting files, right now?

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2022-03-19 06:48]:
> hw <hw@adminart.net> writes:
> 
> > > But why isn't your code located in a buffer visiting a file?
> >
> > It is.  The output of perltidy replaces it.
> 
> Ok - but does it have to be auto-save?  Why not just use normal backup
> files?  You can explicitly force the creation of backup files.  And keep
> a lot of them around.  See (info "(emacs) Backup") and
> (info "(emacs) Backup Deletion").  You can, for example, have hundred
> backups of each file you edit - in a folder of your choice so that they
> don't clobber your working directories.

Exactly so.

My backup files look as these:

  -rw-r--r-- 1  19K Feb  7 19:36 double-opt-in.el
  -rw-r--r-- 1  19K Aug 11  2021 double-opt-in.el~

In reality I almost never use them.

> If you are familiar with git, I suggest to have a look at Magit and the
> wip modes.  After some setup, you get a backup for every save - or even
> two, if the original state of the file was not yet backed up.  Due to
> git's delta compression it doesn't waste much disk space.  The interface
> lets you browse the versions and diff them etc.

Good idea.

I got tired of it all and made 

Emacs: RCD Version Control system with PostgreSQL backend: 
https://hyperscope.link/3/6/7/9/6/Emacs-RCD-Version-Control-system-with-PostgreSQL-backend-36796.html

And now it is all without thinking and my backup files I just recall
by using a function. Not as sophisticated, though very automatic. 

A version of file is in the database. If I need it, I get it
back. Sometimes I do need to repair functions from past. If the file
name location change, I will still be able to find the file in the
database, or save it to file system from there. 

                             ID   44774
                   Date created   "2022-03-19 13:17:14.745576"
                  Date modified   nil
                   User created   "maddox"
                  User modified   "maddox"
                          Table   nil
                         Column   nil
                       Table ID   nil
                          Value   "-- \\i /usr/share/postgresql/8.3/contrib/insert_username.sql ..."
                  PGP Signature   nil
              Short description   "Automatic revision: 2022-03-19-15:17:13"
                    Description   nil
                      File name   "/home/data1/protected/public_html/rcd-business/rcdbusiness.sql"
                       Revision   nil
                         Buffer   nil
                         Schema   nil
                       Database   nil
                       Hostname   nil


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/