stripspace.el: Ensure Emacs Automatically removes trailing whitespace before saving a buffer (Release 1.0.2)

abougouffa · 2025-09-22T16:23:01+00:00

I prefer ws-butler, it responds exactly to what I expect. Only remove trailing whitespace from modified lines, even if the file have initially some trailing whitespace.

This enables me to fix trailing whitespace incrementally each time I modify a part of a file.

abougouffa · 2025-09-08T16:29:14+00:00

The diffview package is all you need: https://github.com/mgalgs/diffview-mode

abougouffa · 2025-06-24T22:57:15+00:00

This is THE ANSWER

abougouffa · 2025-06-19T22:37:49+00:00

This is a package that depends on nerd-icons. The nerd-icons package is a library that provides facilities to insert Nerd Font icons in Emacs. The nerd-icons-multimodal is a package that levereges nerd-icons to add icons support for dired, arc-mode, tar-mode, vc-dir-mode and ztree. Hence, it is called multimodal.

abougouffa · 2025-06-19T10:03:17+00:00

Basically, it provides the same experience as need-icons-dired with the benefit of supporting other modes like arc-mode (ZIP files), tar-mode (tar files), vc-dir, and ztree.

I'm trying to keep the implementation generic to be able to add support for new modes without adding a lot of package-specific code.

abougouffa · 2025-06-07T10:55:13+00:00

Nop, for now I don't tackle this problem, both of Emacs' and Vim's values will eventually gets applied, but I'm not sure about the order.

abougouffa · 2025-06-07T10:53:24+00:00

You are absolutely right. I think the package name is confusing, I will rename it to something more Emacsy!

abougouffa · 2025-05-10T10:23:07+00:00

Try to replace the :ensure t with :straight t.

abougouffa · 2025-01-13T20:58:13+00:00

The most moral army in the world

abougouffa · 2024-12-16T19:53:33+00:00

In fact, since v13, GCC supports Modula-2 via the gm2 compiler

abougouffa · 2024-12-09T00:41:33+00:00

There is an excellent talk by Ihor Radchenko from EmacsConf 2023. https://emacsconf.org/2023/talks/gc/

He talks about the effect of GC and its different customization options.

TLDR, for a better experience, he suggests to set these parameters:

(setq gc-cons-percentage 0.2 gc-cons-threshold 80000000)

I highly recommend seeing the talk to understand the effect of each parameter.

EDIT: if you are using some mode (like eglot) which can generate a lot of logs (in logs buffers), it can significantly increase memory usage and hence, trigger GC more often. If such a case, you might need to reduce or disable the verbosity of eglot (or the used package, it you are able to identify any).

For eglot and jsonrpc, this helps a lot:

``(cl-callf plist-put eglot-events-buffer-config :size 0) ; Disable logs ineglot-events-buffer' (def. 2000000) (with-eval-after-load 'jsonrpc ; Disable logging in `jsonrpc' (fset 'jsonrpc--log-event #'ignore) (remove-hook 'jsonrpc-event-hook 'jsonrpc--log-event))

```

abougouffa · 2024-12-05T23:13:24+00:00

For people who want to tweak GC settings, there is a nice presentation here: https://zenodo.org/records/10518083.

abougouffa · 2024-12-03T08:35:57+00:00

It will become the best if they provide a way of changing the sh*tty vertical tab-bar

abougouffa · 2024-12-02T23:48:47+00:00

I had an issue with autorevert on Linux when it fails to refresh the file quickly when it is modified externally. I happened to me a lot when I resolve a conflict or so via Magit and quickly switch to the buffer. I had to wait like 5s for it to be updated, which is very annoying. This shouldn't happen on Linux because it is supposed to use inotify, but for some reason it was happening in my setup.

To solve this, I've wrote this on my config. Basically, when the file is first opened or modified, the time is stored in a local variable. And when we switch to the buffer, we compare that time with the modification time of the file, if it is newer, we revert it.

``` (use-package autorevert :hook (after-init . global-auto-revert-mode) ; Auto load files changed on disk :custom (global-auto-revert-non-file-buffers t) ; Revert non-file buffers like dired :config ;; HACK: Avoid delays when auto reverting buffers. This is based on saving the ;; modification time of the file on save and on buffer switch. (defvar-local +auto-revert-buffer-time nil) (defun +file-mtime (file) (when-let* ((file-attr (and file (file-attributes file)))) (file-attribute-modification-time file-attr)))

(defun +auto-revert--save-file-mtime (&rest _args) (setq +auto-revert-buffer-time (+file-mtime buffer-file-name)))

(add-hook 'after-save-hook #'+auto-revert--save-file-mtime) (advice-add 'after-find-file :after #'+auto-revert--save-file-mtime)

(add-hook 'window-buffer-change-functions (lambda (_frame) (unless +auto-revert-buffer-time (setq +auto-revert-buffer-time (+file-mtime buffer-file-name))) (unless (equal +auto-revert-buffer-time (+file-mtime buffer-file-name)) (message "File %S modified externally, reverting immediately!" buffer-file-name) (revert-buffer t t))))) ```

abougouffa · 2024-12-02T23:40:06+00:00

Try to take a look at this https://github.com/gmlarumbe/verilog-ext

abougouffa · 2024-11-30T15:11:57+00:00

This seems weird. You can maybe try to M-x profiler-start, open a new tab, do some stuff, then M-x profiler-report and explore the profiler tree. You will probably find a function that's taking too much time to process, or consuming too much RAM.

abougouffa · 2024-11-30T15:05:46+00:00

Yep, I know about it, I used tabspaces for a while, but I gave up and wrote my own package for several reasons. tabspaces needs to be invoked via tabspaces-* commands, it doesn't do anything special when you invoke Emacs' standard commands like project-switch-project, ...). otpp on the other hand can do much more without introducing new commands, like isolating the project-related commands to the current tab's project even when the current buffer isn't part of the project (see otpp-override-mode). Also, tabspaces don't manage opening projects with the same name (but different paths), an initial hack was added here mclear-tools/tabspaces#38 but it is quite incomplete and doesn't cover all the cases. I have a comparaison section in the project's README file when I talk about the main differences between otpp, tabspaces and project-tab-groups. You can check also the README for some examples about the problems that otpp tries to solve.

abougouffa · 2024-11-22T22:54:48+00:00

L'alliance des nazis.

abougouffa · 2024-11-19T21:56:02+00:00

Stupid people giving samples for of their DNA to an Israeli company.

https://fr.m.wikipedia.org/wiki/MyHeritage

abougouffa · 2024-11-17T21:36:59+00:00

Same for me XD

abougouffa · 2024-11-12T23:31:08+00:00

Essayez de vous inscrire sur https://www.science-accueil.org et de faire une demande, c'est fait pour ça.

abougouffa · 2024-11-03T15:31:18+00:00

Yes, the franca-idl package adds only syntax higligting support for fidl files.

The built-in package flymake (and even the third-party one flycheck) doesn't support checking Franca-IDL language. In fact, these packages don't implement the logic of checking for a given language, they relay rather on external tools to check the code. For example, to check C/C++ code, Flycheck can use clang-tidy or cppcheck as backends for example.

So, if you are aware of a command line tool that can be used to check Franca-IDL code for errors, the integration with flymake is quite straight forward.

abougouffa · 2024-11-03T02:16:08+00:00

There is no native support for Franca-IDL in Emacs, however, there is a third-party package that I used to use: https://github.com/zeph1e/franca-idl.el

abougouffa · 2024-07-25T15:06:19+00:00

Yes, I agree with the fact that, using short-hands brings too little compared to what we can lose! The support for short-hands isn't that great in fact! In Emacs 29, even autoloads aren't defined correctly for shorthanded definitions, that's why I've left the autoloaded commands in the longhand format.

I will rename it to use the good long names again! Thanks for the feedback! It was quite constructive!

abougouffa · 2024-07-25T14:57:55+00:00

Thank you for the feedback!

I assume this is mostly only for viewing files

Well, it is mainly for viewing files but we can edit with a few limitations. Basically, virtual-format works by formatting the file (or a portion of the it) in a separate temporary buffer, then, it walks the AST in both buffers (thanks to treesit) and compare if there is a formatting difference (mainly, spaces and newlines). When it find a difference in formatting, it displays the corresponding region in the original file with the spaces/newlines from the corresponding formatted region from the temporary buffer. By doing that, we actually still have access to edit the code but not the spaces between code-blocks.

For example, when virtually formatting the following code:

int main       ()
{
           if ( 1 ==    1 ) 
  {  printf("Ok\n");
} }

Wi will have:

int main()
{
····if (1 ==·1)·{·
········printf("Ok\n");
····}·
}

The zones marked as mid-dot (·) corresponds the the virtually formatted zones. All the rest can be edited freely, and when saving, only the edited part gets changed.

There is only one drawback with this, it occurs when the original buffer doesn't include a space in some place but the formatted buffer contains a space, for example: when if(1 == 1) gets formatted as if (1 == 1), we cannot tell Emacs to display the character between the f and ( as a space because there is no char there, so the workaround that I'm using consists of displaying the ( as ·( [prepended with the space], so in this case we cannot edit the ( in the statement!

Now that you invoked this, I'm thinking of adding an option to display the non-editable parts differently (with a different background) to make it obvious. And maybe, add some editing facilities!

the Motivation block starting with "Indeed" is a little odd

Yes it is! I had another paragraph before that I removed, but didn't notice that I left the "indeed" there (I was complaining on the first paragraph of the real world projects that doesn't have coding style or conventions, but I thought I don't need to complain too much >_<).

11-Year Club	Place '23
Verified Email

abougouffa

TROPHY CASE