4 ms·

Most of these suggestions are either bad or useless. The only one I can get behind is to use spaces for indentation instead of using a mix of tabs and spaces.

Most of these suggestions are either bad or useless. The only one I can get behind is to use spaces for indentation instead of using a mix of tabs and spaces. Other than that: author has some very unique problems (changing fonts so often that they need to adjust how Emacs window fills the screen). Most people change fonts... never. A small fraction -- once or twice, at the time they install and configure the system. The author might be the only person in the world with that problem, but acts as if everyone does the same, and needs a solution. Author doesn't understand why file backups are done they way they are done and advises to make them less reliable. Putting all backups in the same directory will be inconvenient for files named in the same way. C-h is one of the first keys anyone learns about Emacs and it's used all over the place in various combinations. Turning this functionality off in favor of a command that already has a key for it is just stupid. Sentences need two spaces between them to distinguish them from acronyms, abbreviations and other uses of punctuation (like in proper names of products or references to pieces of code). This is the easiest way to deal with this problem. If you don't write two spaces at the end of a sentence, the editor will not be able to reliably determine where the sentence ends, and will screw up your formatting every now and then.

elsjaako 3y ago
I also don't understand why the backups are done the way they are. Why not just copy the current file to the backup, and not break hardlinks?
- tmtvl 3y ago
  I agree, backup-by-copying should be t by default.
  - pama 3y ago
    There are good reasons for the Emacs default that relate to atomic operations in typical file systems, reliability in shady hardware, or power losses and recovery. The argument of the author about hard links breaking is a matter of choice; some people want this copy on write semantics, others call it broken. Most people would want to avoid hard links to editable files anyways.
    - elsjaako 3y ago
      Can you explain some of these reasons? I feel like there is an opportunity for me to learn something here. I don't know enough about filesystems to be sure, but I feel like there are more opportunities for stuff to fail with the move-and-copy technique. E.g. when moving the file it could end up existing twice (if creating the new link happens before removing the old one) or being lost (if removing the old link happens before creating the new one). If you just copy the file, the copying can fail and you don't have a backup. But if the original is still fine then you never notice a problem with the backup, so this option is preferable (as I understand it). > Most people would want to avoid hard links to editable files anyways. Why would you want to avoid this? I though it would be something that Linux can easily handle.
      - pama 3y ago
        Here is a breakdown of some of your questions: 1. Atomicity of Rename Operations: On many file systems, the process of renaming a file is atomic. This means that the operation either completes in full or doesn’t take effect at all. This makes it safer in cases where there might be interruptions, such as power losses. If the rename (which creates the backup in Emacs’s default behavior) is interrupted, you’re left with the original file intact. 2. Concern about Move-and-Copy Technique: Your point about the possibility of the file ending up existing twice or being lost is valid in theory. However, in practice, the renaming operation ensures that such intermediate states are avoided. A rename isn’t quite the same as creating a new link before removing an old one. Instead, it’s a reassignment of the file’s metadata, which is generally a reliable operation. 3. Drawbacks of Just Copying: While just copying the file might seem simpler, it can have issues. If there’s an interruption while writing the new copy, you can end up with a corrupted backup. With Emacs’s approach, since the original is renamed (and thus preserved in its entirety), you’re always assured of having at least one uncorrupted version. 4. Avoiding Hard Links to Editable Files: As for the avoidance of hard links for editable files, there are a few reasons: Ambiguity: Editing a file that’s hard-linked elsewhere can lead to confusion since changes reflect in all linked locations. This can be unexpected for those unaware of the link. Data Integrity: If there’s corruption in one location, it affects all hard-linked locations. Backup Issues: Some backup systems might not handle hard links as expected, leading to either duplicate data or missed backups. Linux does handle hard links well, but their usage needs careful consideration, especially when editing is involved. They’re great for static data that doesn’t change but can be problematic for editable files. I hope this clarifies things!
- bananapub 3y ago
  writing to a temp file then renaming it to the real location is a long held tradition to avoid partial writes and filesystem corruption if power is lost
  - crabbone 3y ago
    Yes. This. If you copy from unsaved file, you are risking to lose both the file you are baking up and the backup.
mksybr 3y ago
They're changing font size, not fonts. I often C-scroll to zoom in, if there isn't a lot of text as I rather big fonts over lots of whitespace.
- crabbone 3y ago
  No idea what C-scroll does. Is it same / similar to C-x C-+ / C-x C--? If so, I think it's designed to increase / decrease in steps that would fit into desired resolution... but I'm not 100% sure about it. This is something I never really use outside of situations where I have to present (i.e. show my screen on some large screen for many people to see and the need me to zoom in / out). I didn't really have problems with this even though I too use a tiling manager (StumpWM).
  - mksybr 3y ago
    >Is it same / similar to C-x C-+ / C-x C--? Yes. C-<wheel-up> at that spot runs the command mouse-wheel-text-scale (found in global-map), which is an interactive native- compiled Lisp function in ‘mwheel.el’. It is bound to C-<wheel-down>, C-<wheel-up>, C-<mouse-5> and C-<mouse-4>. (mouse-wheel-text-scale EVENT) Adjust font size of the default face according to EVENT. See also ‘text-scale-adjust’. >the need me to zoom in / out I just prefer it, if I have little text, for it to be big. Why waste it on whitespace?
pama 3y ago
I agree. Emacs defaults are battle hardened and work well in exotic and regular hardware for all kinds of use cases. I modify defaults to remove the extra fluff (tool bars, menus, scroll bars, yes-or-no), but I see their value to new users. Luckily Emacs is the most customizable editor on the planet so everyone can be happy using it and write their thoughts about it.
eviks 3y ago
Speaking of understanding: > command that already has a key for it is just stupid backspace is one of the most inconvenient keys, so there is nothing stupid about replacing it with a much more convenient alternative (though the Ctrl default of Emacs is another bad default) And he's changing the font size, not font > Putting all backups in the same directory will be inconvenient for files named in the same way. if only it were somehow possible to create subfolders or slighly change the names and store links in the backup...
- crabbone 3y ago
  > backspace is one of the most inconvenient keys Even when I used a more traditional "straight" keyboard I didn't have problems with it... Also, it's usually bigger than character and digit keys, so, really, it's not that hard to press it... > so there is nothing stupid I literally wrote what is stupid about it. Please take a minute to read the post you are replying to. > if only it were somehow possible to create subfolders or slighly change the names and store links in the backup... This is irrelevant. What if you rename the directory where you worked with files that need backups? Even worse, what if you switched two directories. Or deleted and created afresh... There are plenty of cases where renaming of backups will be very confusing / will do something you didn't intend and for zero gain.
  - eviks 3y ago
    It doesn't matter whether you had problems, you just need to understand that it's easy for other people to have them (the fact that it's bigger doesn't change the fact that it's one of the worst) to realize it's not stupid to replace with a more convenient convention that you use elsewhere You literally wrote what is stupid with two factors, I wrote why it's not emphasizing the 2nd, so? The frequency of use alone isn't enough, backspace is used even more frequently, so it's more important, hence, again, not stupid to swap > for zero gain The gain is mentioned right at the top of the post, so that's not zero My response was relevant to the issue your raised with file names, your new what ifs are what's not relevant to that exchange

elsjaako 3y ago

I also don't understand why the backups are done the way they are. Why not just copy the current file to the backup, and not break hardlinks?

tmtvl 3y ago
I agree, backup-by-copying should be t by default.
- pama 3y ago
  There are good reasons for the Emacs default that relate to atomic operations in typical file systems, reliability in shady hardware, or power losses and recovery. The argument of the author about hard links breaking is a matter of choice; some people want this copy on write semantics, others call it broken. Most people would want to avoid hard links to editable files anyways.
  - elsjaako 3y ago
    Can you explain some of these reasons? I feel like there is an opportunity for me to learn something here. I don't know enough about filesystems to be sure, but I feel like there are more opportunities for stuff to fail with the move-and-copy technique. E.g. when moving the file it could end up existing twice (if creating the new link happens before removing the old one) or being lost (if removing the old link happens before creating the new one). If you just copy the file, the copying can fail and you don't have a backup. But if the original is still fine then you never notice a problem with the backup, so this option is preferable (as I understand it). > Most people would want to avoid hard links to editable files anyways. Why would you want to avoid this? I though it would be something that Linux can easily handle.
    - pama 3y ago
      Here is a breakdown of some of your questions: 1. Atomicity of Rename Operations: On many file systems, the process of renaming a file is atomic. This means that the operation either completes in full or doesn’t take effect at all. This makes it safer in cases where there might be interruptions, such as power losses. If the rename (which creates the backup in Emacs’s default behavior) is interrupted, you’re left with the original file intact. 2. Concern about Move-and-Copy Technique: Your point about the possibility of the file ending up existing twice or being lost is valid in theory. However, in practice, the renaming operation ensures that such intermediate states are avoided. A rename isn’t quite the same as creating a new link before removing an old one. Instead, it’s a reassignment of the file’s metadata, which is generally a reliable operation. 3. Drawbacks of Just Copying: While just copying the file might seem simpler, it can have issues. If there’s an interruption while writing the new copy, you can end up with a corrupted backup. With Emacs’s approach, since the original is renamed (and thus preserved in its entirety), you’re always assured of having at least one uncorrupted version. 4. Avoiding Hard Links to Editable Files: As for the avoidance of hard links for editable files, there are a few reasons: Ambiguity: Editing a file that’s hard-linked elsewhere can lead to confusion since changes reflect in all linked locations. This can be unexpected for those unaware of the link. Data Integrity: If there’s corruption in one location, it affects all hard-linked locations. Backup Issues: Some backup systems might not handle hard links as expected, leading to either duplicate data or missed backups. Linux does handle hard links well, but their usage needs careful consideration, especially when editing is involved. They’re great for static data that doesn’t change but can be problematic for editable files. I hope this clarifies things!
bananapub 3y ago
writing to a temp file then renaming it to the real location is a long held tradition to avoid partial writes and filesystem corruption if power is lost
- crabbone 3y ago
  Yes. This. If you copy from unsaved file, you are risking to lose both the file you are baking up and the backup.

mksybr 3y ago

They're changing font size, not fonts. I often C-scroll to zoom in, if there isn't a lot of text as I rather big fonts over lots of whitespace.

crabbone 3y ago
No idea what C-scroll does. Is it same / similar to C-x C-+ / C-x C--? If so, I think it's designed to increase / decrease in steps that would fit into desired resolution... but I'm not 100% sure about it. This is something I never really use outside of situations where I have to present (i.e. show my screen on some large screen for many people to see and the need me to zoom in / out). I didn't really have problems with this even though I too use a tiling manager (StumpWM).
- mksybr 3y ago
  >Is it same / similar to C-x C-+ / C-x C--? Yes. C-<wheel-up> at that spot runs the command mouse-wheel-text-scale (found in global-map), which is an interactive native- compiled Lisp function in ‘mwheel.el’. It is bound to C-<wheel-down>, C-<wheel-up>, C-<mouse-5> and C-<mouse-4>. (mouse-wheel-text-scale EVENT) Adjust font size of the default face according to EVENT. See also ‘text-scale-adjust’. >the need me to zoom in / out I just prefer it, if I have little text, for it to be big. Why waste it on whitespace?

pama 3y ago

I agree. Emacs defaults are battle hardened and work well in exotic and regular hardware for all kinds of use cases. I modify defaults to remove the extra fluff (tool bars, menus, scroll bars, yes-or-no), but I see their value to new users. Luckily Emacs is the most customizable editor on the planet so everyone can be happy using it and write their thoughts about it.

eviks 3y ago

Speaking of understanding: > command that already has a key for it is just stupid backspace is one of the most inconvenient keys, so there is nothing stupid about replacing it with a much more convenient alternative (though the Ctrl default of Emacs is another bad default) And he's changing the font size, not font > Putting all backups in the same directory will be inconvenient for files named in the same way. if only it were somehow possible to create subfolders or slighly change the names and store links in the backup...

crabbone 3y ago
> backspace is one of the most inconvenient keys Even when I used a more traditional "straight" keyboard I didn't have problems with it... Also, it's usually bigger than character and digit keys, so, really, it's not that hard to press it... > so there is nothing stupid I literally wrote what is stupid about it. Please take a minute to read the post you are replying to. > if only it were somehow possible to create subfolders or slighly change the names and store links in the backup... This is irrelevant. What if you rename the directory where you worked with files that need backups? Even worse, what if you switched two directories. Or deleted and created afresh... There are plenty of cases where renaming of backups will be very confusing / will do something you didn't intend and for zero gain.
- eviks 3y ago
  It doesn't matter whether you had problems, you just need to understand that it's easy for other people to have them (the fact that it's bigger doesn't change the fact that it's one of the worst) to realize it's not stupid to replace with a more convenient convention that you use elsewhere You literally wrote what is stupid with two factors, I wrote why it's not emphasizing the 2nd, so? The frequency of use alone isn't enough, backspace is used even more frequently, so it's more important, hence, again, not stupid to swap > for zero gain The gain is mentioned right at the top of the post, so that's not zero My response was relevant to the issue your raised with file names, your new what ifs are what's not relevant to that exchange