emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: frustrations


From: Tim Cross
Subject: Re: frustrations
Date: Thu, 02 Dec 2021 09:12:38 +1100
User-agent: mu4e 1.7.5; emacs 28.0.60

Jan Ulrich Hasecke <juh+org-mode@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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]