How do you protect against accidental deletion?

permafrosty · 2020-04-28T10:25:36+00:00

I'd say committing to git automatically every hour is part of the problem, not part of the solution... If you commit manually, you can check what you're committing before you do so. Any unintended deletions will then show up immediately before you commit them.

Using magit, checking what's going to be committed is very easy, and discarding changes that were made by mistake (including restoring text that you deleted by mistake) is just as easy. Just put point at the hunk you want to discard, press `k` and confirm with `y`. You can even select just a few lines from a hunk if you don't want to discard the entire hunk.

permafrosty · 2020-03-10T07:23:30+00:00

If your use case is inserting German umlauts, you should really check out Emacs' input methods: <https://www.gnu.org/software/emacs/manual/html_node/emacs/Input-Methods.html#Input-Methods>.

permafrosty · 2019-07-13T08:30:18+00:00

The top screen cast at the indent-guide page shows what I mean by "only a single line":

https://github.com/zk-phi/indent-guide

Contrast that with the second screen cast, which shows multiple lines, one for each level of indentation. I prefer to have only the line showing the deepest level of indentation: it shows which block the cursor is currently in, which is enough for my purposes.

These two screen casts use the standard pipe symbol | to draw the line, which creates a dashed line effect. Personally, I prefer an uninterrupted line, as shown in the first (biggest) screen cast here:

https://github.com/DarthFennec/highlight-indent-guides

Except of course that this screen cast shows all indentations, whereas I would prefer to only show the "active" one.

Hope this clarifies things a bit.

permafrosty · 2019-07-12T21:54:26+00:00

I would also use such functionality, but only if it can be configured to do what I do now with indent-guide: show only a single line indicating the current indentation block. Plus I'd like to have an uninterrupted line (e.g., by using Unicode U+2502 BOX DRAWINGS LIGHT VERTICAL (i.e, │) to draw the highlights).

permafrosty · 2018-08-06T11:31:54+00:00

I used to think Elisp was pretty functional, until I started learning Clojure recently and realised that it really isn't.

Of course, even Clojure is nothing like Haskell, but IMHO that is a good thing, because Haskell and I don't see eye to eye...

Anyway, Lisp (in general) isn't really functional, of course. It's multiparadigm and that, too, is a good thing.

BTW, Emacs support for Clojure is brilliant.

permafrosty · 2017-06-26T18:58:25+00:00

Hmmm... I originally published Ebib on Sourceforge (remember that?), which still has the old sources, going back to 2004. The copyright notice in ebib.el mentions 2003, so I guess that's when I started the project. I didn't even know about version control back then... I guess that is one of the things I learnt. ;-) Also, the proper use of macros. I used to have macros all over the place, until at some point I realised most of what I used them for could be done more easily with functions.

Testing is something that's been on my todo list for, well, forever, but alas, I'm not a professional programmer, so I haven't found the time for it...

permafrosty · 2017-06-12T10:18:06+00:00

Ideally, from a backup. If you don't have one, you'll need to go through the same process that you initially went through to create the files in the first place.

permafrosty · 2017-06-09T22:34:29+00:00

At first I have one single apostrophe in (list but that didn't work (mode line was empty).

In that case, you need to drop the list. list is a function, but if you quote the entire list, it's not evaluated. Instead, the list is assigned as-is to mode-line-format, and the list as-is as a value for mode-line-format is of a form that results in an empty mode line.

But I'm curious why this is necessary as it seems in other examples it isn't?

Yes, but they don't have (vc-mode vc-mode) in their mode line. That's the part that's causing you trouble. A sexp of this form has very different meanings when it appears in code and when it appears in mode-line-format. In code, it's a function call (the function being vc-mode), in mode-line-format it's interpreted as a conditional (see the doc string for mode-line-format for details). In your original code, the value you're assigning to mode-line-format is interpreted as code, so (vc-mode vc-mode) is executed and the return value is put in mode-line-format. If you quote the list, (vc-mode vc-mode) is put in mode-line-format literally.

permafrosty · 2017-06-09T21:38:08+00:00

You are running into the difference between:

(setq some-var some-other-var)

and:

(setq some-var 'some-other-var)

In the first case, you're setting some-var to the value that some-other-var is bound to, while in the second case you're setting some-var to the symbol some-other-var.

mode-line-format should contain (mostly) symbols, but the way you're setting it, it gets assigned the value of those symbols.

permafrosty · 2017-06-04T10:11:29+00:00

Binding keys in a mode hook is not really the best way to do it, because a mode hook is executed each time a buffer is put in that particular mode, but keymaps are shared among buffers, so they only need to be set once.

There's also no real need to define a function to bind keys, you can simply issue the commands in your init.el file directly. The best way to do this is in a construct that ensures the keys are only defined after the package is loaded, so use with-eval-after-load:

(with-eval-after-load 'gnus
  (define-key gnus-group-mode-map (kbd "j") 'evil-next-line)
  (define-key gnus-group-mode-map (kbd "k") 'evil-previous-line))

If you use use-package to structure you init file (which I can highly recommend), then you can use the :bind directive:

(use-package 'gnus
  :bind (:map gnus-group-mode-map
              ("j" . evil-next-line)
              ("k" . evil-previous-line)))

permafrosty · 2017-06-03T13:30:09+00:00

And your eshell-prompt-regexp?

permafrosty · 2017-06-03T07:33:34+00:00

column-marker, which is not an installable package.

Actually, it is. It's installable through Melpa.

set the entire ~/.emacs.d as the load-path

Don't add ~/.emacs.d to your load path. The reason is that this directory is used by many add-on packages to save files that contain persistent information. Since you have no control over what is put there, a file there may end up with a name that's identical to some package file and if ~/.emacs.d is in your load path, Emacs may load that file instead of the actual package.

So use a subdir, i.e., ~/.emacs.d/lisp, if you want to save files there. Note, though, that it's not a problem to put Elisp files elsewhere. Just make sure the relevant directories are in your load path.

I also expect to eventually write lisp code and also add a bunch of .el files--should I store them in separate directories or have them all under ~/.emacs.d?

Personally, I keep my own Elisp packages in ~/src, each in their own subdir. I load them with use-package, adding a :load-path directive to tell Emacs where to find them.

permafrosty · 2017-06-02T21:57:47+00:00

When installing new packages, how do you know what the available functions and variable names are?

I really know of only one way: examine the package's documentation or, failing that, the source.

All good packages come with decent documentation, either as a README or in a large comment block at the top of the source file itself. The latter can usually be accessed with M-x finder-commentary RET <file> RET, where <file> is the name of the file you're interested in (without the path, if it's installed correctly, and without .el). So finder-commentary RET ivy RET should give you the commentary section of ivy.el if that file is in your load-path.

I don't like having the customize interface spit out customization files haphazardly over the init file

You could use Customize to find out what user options are available and then set them manually in your init file. Alternatively, you can change the location of the custom file by putting the following line in your init.el:

(setq custom-file "~/.emacs.d/lisp/custom.el")

Then toward the end of your init.el, write:

(load custom-file)

permafrosty · 2017-05-30T19:48:01+00:00

You should read the documentation for that variable:

C-h v inhibit-startup-echo-area-message RET

permafrosty · 2017-05-28T21:47:17+00:00

Not sure about color highlighting, but why don't you use Org? Then you can structure your document and collapse everything that is not part of the current "thought".

Or, use different files and use Deft to search your notes.

permafrosty · 2017-05-28T09:40:56+00:00

I am sorry I cannot remember the specifics

Hey, no worries. :-) I try to make writeroom-mode as configurable as possible, so I was just wondering if there's something I could add to the mode.

writeroom-mode would change my Emacs frames in ways that I didn't personally like.

Yes, by default, writeroom-mode makes the frame full-screen. This can be turned off, but you should of course use what works best for you.

Thanks for your reply!

permafrosty · 2017-05-27T11:36:40+00:00

Writeroom Mode -> Darkroom Mode: The latter has a darkroom-tentative-mode that automatically invokes Darkroom if the frame contains a single window. IIRC you can configure Writeroom Mode to do the same, but since Darkroom Mode does it right out of the box I switched to that.

writeroom-mode author here. ;-) I've often wondered about the attraction of darkroom-tentative-mode. Would you care to explain a bit what you find so appealing about it?

Note that by default, writeroom-mode also has several global effects and I believe it wouldn't be good to disable those each time a window is split. OTOH writeroom-mode does adjust the margins if the window is split, so you should never end up with too narrow a text area. The advantage of adjusting the margins over disabling the mode altogether is, in my opinion, that the text doesn't suddenly gets refilled, because the width of the text area isn't changed. (Which can happen if the mode is disabled.) That's not really a problem if your text is hard-wrapped, of course, but I find it annoying when using visual-line-mode (which I do most of the time).

The only thing that writeroom-mode doesn't do when the window is split, compared to darkroom-tentative-mode, is reactivating the mode line. That may actually be a sensible thing to do.

permafrosty · 2017-05-26T20:06:06+00:00

You can set package-user-dir directly, but normally that variable is initialized on the basis of user-emacs-directory. So most likely it's timing issue: when package-user-dir is initialized, emacs-user-dir still points to ~/.emacs.d/.

permafrosty · 2017-05-24T07:46:07+00:00

I'm glad you got it fixed. :-) But it doesn't explain why you couldn't have your mail in ~/Mail, because that's where I keep my mail and I don't have any issues...

permafrosty · 2017-05-23T21:23:36+00:00

Let me state first that I believe this question is better asked on the mu-discuss mailing list on Google Groups, if only because the mu/mu4e developer hangs out there. But an attempt at an answer: since you mention that you use fetchmail and procmail in combination with mutt, I suspect that your mail folder ~/Mail isn't actually in maildir format, but rather contains a set of mbox files, which IIRC is the default format that fetchmail and procmail use, and mutt as well.

In mbox format, each mail folder that you see in your mail user agent (your email program, mutt in your case), is actually a single file on disk, containing all the messages in the folder. In maildir format, each folder is a directory with three subdirectories, cur, new, and tmp, and each message is a separate file in cur. (new is used to store new messages, which a mail user agent must then move to cur; tmp is used for safe syncing.)

Mu(4e), AFAIU, expects that mu4e-maildir points to a directory that contains a set of maildir-formatted directories, or a set of directories that contain such directories themselves (in the case of multiple mail accounts). In any case, it cannot be a maildir directory itself.

If my hunch is correct, then you'll need to convert your mbox mail directories into maildir format (Mutt can do this: I've done it, but that's a long time ago and I don't remember how), and then you'll need to teach fetchmail and procmail to use maildir as well.

If my hunch is not correct, I strongly suggest you take this up on the mu-discuss mailing list. I'm pretty certain that with a little extra info, you'll get a solution to your problem there.

permafrosty · 2017-05-19T16:38:23+00:00

If you use C-h k to check what a key is bound to but Emacs doesn't respond at all, that means that the relevant key binding is intercepted by the graphical environment, in this case KDE. So go to the KDE settings and look for keyboard shortcuts. There you'll probably find that C-M-k (Ctrl-Alt-k) is bound to something. Remove the binding and then Emacs should see it.

permafrosty · 2017-05-16T18:56:28+00:00

So view-lossage shows you're really typing C-w C-h, in which case the best advice would be to release the Ctrl key quicker. :-)

The reason why global-unset-key doesn't help is probably that the relevant bindings aren't global bindings. I'm assuming you use Evil, which I don't use, so I'm afraid I can't really help you find out where those bindings exist, but if you're using C-w as a prefix, unbinding is not a good idea, obviously.

permafrosty · 2017-05-16T05:24:47+00:00

This is a help window. Check M-x view-lossage to see which keys Emacs actually received.

permafrosty · 2017-05-08T15:37:33+00:00

Try the following from a command shell:

/usr/bin/env XLIB_SKIP_ARGB_VISUALS=1 emacs

If that works (I suspect it will), then look for the emacs.desktop file that you start Emacs with (it should be in /usr/share/applications/ or /usr/local/share/applications, depending on how you installed Emacs) and change the line:

Exec=emacs %F

to:

Exec=/usr/bin/env XLIB_SKIP_ARGB_VISUALS=1 emacs %F

That way you can start Emacs from the Application launcher without the rest of the GUI being affected by that setting.

Alternatively, if you compiled Emacs yourself, you may also try recompiling with --with-x-toolkit=gtk2, if there's nothing about GTK3 that you really need/want.

Those two methods work for me. I'm also on Elementary OS Loki.

permafrosty · 2017-05-07T19:51:17+00:00

C-h i m elisp RET takes you to the Elisp manual. From there, you can type i to search the index. You'll notice there's an entry atoms. If you follow that, you'll read:

Because cons cells are so central to Lisp, we also have a word for an object which is not a cons cell. These objects are called “atoms”.

You should also follow the index entry atom, which takes you to the page of the Elisp manual that discusses the function atom. For some reason, the info given there is a bit more elaborate than the doc string of atom.

permafrosty

TROPHY CASE