You, sir, deserve a medal

[dcunited001]

I haven't spent enough time looking into everything yet, but the tooling and docs here are amazing.

[dcunited001]

I've had quite a bit of trouble grokking ediff. I haven't read through all its manuals, but i have studied the commands and keybindings. I don't need to use ediff all that often, but when I do, it would be super-valuable. However, it doesn't quite work the way I expect.

Anyways, this diff-merge guide and many others help a lot. Your GNU Make guide is superb. The layouts are concise & dense, so they print easily.

[dcunited001]

I need to take a look at the updates.

[dcunited001]

@pierre-rouleau i had printed out the main PDF before. it's a good overview on different parts of emacs that one should configure or at least know about.

the selection of languages in this project is also pretty impressive. i like the use of function-key maps/bindings as well. I reserve the super key for the OS, so anything that includes it is assumed to be window manager or OS, but I explicitly unmap everything that doesn't include it in i3 or KDE. doing that makes life quite a bit simpler.

[pierre-rouleau]

Hi @dcunited001 , I tried to leave as many of the original Emacs key bindings untouched, except when there was a conflict with something else I use. I also try to make commands available to Emacs running in terminal mode without too many hoops. I often need to access remote Linux nodes for the contracts I'm working on. Although it's always possible to use Tramp, most of the time I prefer accessing the system over ssh, using GNU screen to protect my sessions and invoke the remote Emacs. That's the main reason I use so many function keys as prefixes.

I am trying to make common bindings for a lot of things but I have not yet achieved what I'd like to have, while keeping support for Emacs starting at 26.1 (which is still used on a lot of systems I need to access), Linux and macOS. I used to also check binding for Windows, but I've been lucky to not have to use Windows in the past years.

All PDFs can be launched in the local PDF viewer or a browser by a context key. It's normally <f12> <f1> for major modes where I support them. Otherwise <f11> p followed by a topic (tab completion supported) can access the PDFs.

Support for a lot of the listed programming languages is far from complete. I'm focusing on the ones I have to use and when I have a moment for the others I's like to use. I am also trying to add functions that display current status and mode of operations and list commands that can be used to configure/control certain things.

These days I'm a little busy with contract work, so I'm only pushing the changes I need in the various systems I use. But if you have ideas of what could improve what I have, let me know.

[dcunited001]

i see. I'm glad you mentioned the terminal and console. I notice that it's a capability that usually has a bit of configuration dedicated to it (in spacemacs or doom emacs or in many .emacs.d configs i've looked at. i do wish i could get more feedback from people on their workflow and usage patterns.

If PEL does this emacs well when running in remote/terminal/console, then I think I'll have to give it a try soon.

I've spent much time thinking on the benefits and costs of managing multiple Emacs configurations.

• To me, some of the UI/UX features like fonts, keys, icons, etc are invaluable, but also limit portability of the profile.
• I have concerns about long-running emacs sessions or all-in-one-sessions. i'm comfortable with Tramp for most things, but there are technical and practical issues. Via Tramp, Org-babel is confusing/difficult, especially across multiple distributions. So, from Guix via SSH to Arch, commands will fail because I have very little that's installed globally.
• creating a new profile is simple enough (esp. with the new --init-directory option) and for the most part, I don't need to do everything everywhere.
• however, it worries me to think about managing the state of about 4 different .emacs.d profiles which may need updated packages, etc.

Tramp has been great. I spent a ton learning about Emacs' remote features. Ultimately I did have the "aha" moment, where I remembered I could just SSH and that would probably be simpler, provided I could manage the remote configuration & state.

Some issues I've run into:

• Linux Console: commands like loadkeys are difficult to understand. They also have hardware-specific coding, though (as long as you know where to look) it's simple enough to find packages for distributions that declaratively specify the coding schemes for various laptops/keyboards. My laptop is almost identical to the HP Dev One, so I found that. I still didn't have great success with loadkeys. I believe I need this loaded before the kernel begins handling much keyboard input.
• Once fonts or incompatible symbols are loaded, they seem to be stuck in emacs.

So i've also tried to retain the possibility of running Emacs in the console. This is for a few reasons.

• If I have a cloud VM that I can ssh to, then I could perhaps run my chat there along with gnus. The main drawbacks: I don't always you have ssh, difficulties supporting fonts & emoji features over tunnel, managing state for Bash profile (or services) may be complicated or and the clipboard doesn't "just work".
• I may need to work something out if Guix system or Arch wouldn't boot. I can usually do everything I need from emacs -q, however, I did have some problems with xsession, where it was useful to stay entirely within the console for a few days.

So far, the .xsession issue was the only use case. I learned a long time ago though that it's much easier to check on terminal portability from time to time than to prune out packages which are incompatible.

[pierre-rouleau]

I have not yet used Org-babel. I use Org mode a little but when I write tech docs I end-up using reStructuredText.

As far as the keyboard settings, I have a configuration for the macOS Terminal.app keyboard that maps what can be mapped there. And for Linux I have various keyboard configurations for the various Linux distributions I use. Some distros I use by choice, others are imposed by the projects. I have not yet written anythin to automate that, never found the time for it.

PEL configuration is based on Emacs customization. There's a bit of logic that must be present inside the init.el and if used, inside the early-init.el files. The init.el invokes the pel startup: pel-init. This is where PEL determines what is needed by checking the values of the various pel-use-.... user-options. When one user-option is non-nil PEL tries to install the required package and use it. Since the pel-use-.... are user-options, the information is stored inside the ~/.emacs.d/emacs-customization.el file .

What I do to support multiple system is install Emacs, install PEL,compile all PEL source files (with the provide make script) and then update the ~/.emacs.d/emacs-customization.el file. with something that I use for a system similar. Next time I open Emacs it installs the missing packages and use the same configuration.

This has its advantages but also its disadvantages. If a package is not supported by PEL it's still possible to install it in the normal/standard package-list package way, but the duplication inside another system is not there.

I don't use emojiis much so I did not run into issues there.

And in most case I can control the systems I use, so I often use ssh and GNU screen and the remote Emacs if I can build a decent version on it. PEL starts supporting Emacs at version 26.1 so that's normally possible even with old LTS versions of Linux that are still being used for running legacy systems.