Jan Ulrich Hasecke <juh+org-m...@mailbox.org> writes:
> Hi all, > > after happily using straight for quite a while I am currently frustrated by a > couple of problems. > > In a different thread I asked about exporting citations, which does not > work for me at all. > > Today I discovered that pamparam does not work anymore with an error > message mentioned here: > https://github.com/nobiot/org-transclusion/issues/105 > > Even to get to this error, as pamparam didn't start at all, I had to > manually fix something in worf.el > https://github.com/leotaku/worf/commit/38e901d3888e3a245a5cba14a061bffa1c5fd20b > > If I understand correctly, straight uses the bleeding of packages from > github. Maybe this is not what I want. Maybe in the past I just was > lucky not to hit a bug or an incompatible change. > > There are some more issues. Startup time of my emacs is more than 30 > seconds even after optimizing something with esup. I have 10.000+ files > in my org-roam and fear that I hit some limitation either of org-roam or > my hardware. > > How do you configure your emacs using current versions like org 9.5 but > at the same time avoiding problems with incompatible packages or newly > introduced bugs? > > In a few days I'll get a new computer and I have serious doubt whether > to copy my settings.org to the new one, because there are too many > problems in the last couple of weeks. > As mentioned by others, this is really a general Emacs and software maintenance issue. However, I'll add a couple of points to what has already been said (most of which is good advice). - Don't use straight. I've never used it primarily because installing directly from git is high risk. There is no guarantee that a git repository is stable or if the head of a branch is fully tested etc. Instead, stick with package.el and in particular, the GNU ELPA and NONGNU repositories. One reason for this is that when an updated package gets into one of the repositories, it does so because the maintainer has released a new version. This is not necessarily the case when you install directly from a git repository (either using straight or git directly). - Often it is useful to steal (borrow) ideas from others. In particular, some of the curated 'canned' emacs setups, like spacemacs and doom implement a package rollback facility. You can upgrade packages and if you find they break your workflow in some way, you can rollback to a previous version. You may not want to use one of these curated configurations. However, this doesn't stop you from taking the ideas (and in most cases, even the code as it is typically GPL'd). These days, I use spacemacs and one reason is because I'm not interested in having to constantly tweak and review my packages and additional libraries. I now just leave that to spacemacs and enjoy the time it saves me. With updates and stability, I think there are two approaches - Update regularly - at least once a week if not more often. Doing this tends to result in only small changes and when things do break, it usually isn't too hard to fix. However, you are more likely to have small breakage more often. I tend to do my updates on Sunday so taht I ahve time to fix any problems before work on Monday. - Only update when you encounter problems and need recent bug fixes or when a package you use has released a new version which has features you want. This results in far fewer instances of things breaking. However, the downside is that when you do upgrade, lots will likely change and tracking down the cause of problems can be more difficult. This approach often requires more planning and takes longer, but you do it less frequently. This I would do during a week off or over a holiday period etc. One trick which I've used in the past is to - Ensure all my library and package dependencies are located under .emacs.d - Use something like use-package to manage installation of additional packages (via the :enable stanza). Before doing an update/upgrade, I make a copy of .emacs.d called emacs.d-yyyymmdd (i.e. emacs.d with the date appended to the name). I then do the update/upgrade. If things a broken, I simply delete .emacs.d and then move the copy back to .emacs.d and I'm back to where I was before the upgrade. It is somewhat crude, but simple and reliable. In reality, I've put lots of my configuration files under git, so I can easily restore a configuration on any system. With regards to startup time, the key thing is to ensure you don't load things until they are needed. Emacs has built in support for this with the 'autoload' facility (get more details from the manual). Alternatively, you can use something like use-package, which has the :deferred stanza that will defer loading a package until a specific command is executed (pretty sure it just uses the autoload facility under the hood). I load approx 500 additional Emacs packages in my setup and my load time is only a cople of seconds. I really like the use-package library. It can make your init.el file much cleaner and you can setup things so that the only thing you need to backup is your init.el file. Whenever you want to do a clean install with all the latest versions of packages, you can just wipe away .emacs.d, copy in your init.el into a fresh .emacs.d directory and then startup Emacs. The first run will be slow as use-pakage downloads all the packages you use, but after that, provided you have used the :defer stanza appropriately, startup times will typically be quite short. Finally, it may be worth looking closely at eh documentation for package.el and use-package as they also provide facilities which may be useful. For example, you can configure things so that packages are pinned to a specific version or specific repository. For example, you could specify that certain key packages will stay at a specific version until you explicitly tell Emacs you want to update to a new version. I've used this for some packages which have high frequency of releases and which are not always stable. This allows me to do do a package update and know that a couple of key packages I really depend on will not change. So, in summary, there are quite a few things you can do to address your frustrations. Unfortunately, the frustrating part is that you will likely need to digest some key manuals and spend some time getting the setup right. I would also suggest sticking to the ELPA and NONGNU package repositories as much as possible. Other repositories, like MELPA, might have more recent versions of some packages, but they tend to be less stable (and are often of greatly varying quality).
