From: Tim Cross <theophilusx@gmail.com>
To: Samuel Wales <samologist@gmail.com>
Cc: Roland Everaert <reveatwork@gmail.com>, Org Mode <emacs-orgmode@gnu.org>
Subject: Re: electric-pair, autopair, smartparens, etc in org-mode
Date: Sat, 27 Oct 2018 08:45:43 +1100 [thread overview]
Message-ID: <87efccl6uw.fsf@gmail.com> (raw)
In-Reply-To: <CAJcAo8u0b2=Z9MgU-cdZK5fX6qC0eB+HwhSbW=_C7dugVwGPfQ@mail.gmail.com>
Samuel Wales <samologist@gmail.com> writes:
> can either of you give examples of code or settings that you had that
> made behavior of new modes unpredictable because emacs started
> supporting the behavior you made the code or settings for?
>
It is difficult to remember now as it was some time ago that I cleaned
up my init and got rid of much of my old stuff. Areas I do remember
include
- Key bindings. This is probably the most common. You would enable a new
Emacs feature only to find you had conflicts with key bindings. In the
best case, some new features couldn't be easily accessed. In the worst
case, a new feature would create unexpected behaviour. The hard part
was often in deciding whether to try and change the bindings or change
my finger memory.
- Hooks. This was probably the second most common problem. A new feature
would add to a hook where I had a similar feature also on that
hook. As a result, both would run and result in unexpected outcomes.
- Convenience functions for selecting files, buffers and windows,
working with sets of files (i.e. projects), My setup predated ido, and
packages like yasnippets, projectile and company mode which I now use. In many
cases, my own tweaks were OK, but not as robust or feature rich as
standard packages that were added to Emacs over releases which
provided similar functionality.
- As my init had grown in a rather 'organic' manner - bits added as I
needed them, there was a lack of consistency or structure to my
configuration. As a result, often when I tried a new feature, there
would be parts of my init I would forget to remove/disable that would
conflict with that feature. As I used autoloads quite a bit, things
would also be a little inconsistent as conflicts could be dependent on
the order things got loaded and that order could be affected by what I
did in a specific session.
- One area I do remember was with respect to handling of PDF, HTML and
other document types. I had a lot of config which would automatically
convert many of these types to plain text to make them easy to work
with inside emacs. As modes like doc-view, eww etc were added. I
recall at times, conflicts would occur. I remember at one point, what
behaviour I would experience when opening a PDF would depend on what
mode had been loaded. If doc-view was already loaded, I would see the
PDF rendered using doc-view - if my code was already loaded, I would
see a plain text version. Often, the result would not be the one I
wanted. I now no longer have all that code in my init and leave such
things to Emacs.
In my case, much of my elisp config was pretty rough - I did as little
as necessary to get the behaviour I wanted. It was often poorly tested,
lacked sufficient error checking, was inconsistent and overall rough -
it did the job. However, this did mean it often did not play well with
others. For ages, I simply didn't bother looking at new features and
modes unless I came across a new requirement e.g. learning a new
programming language, working with a new system etc. My init also had
large amounts of code borrowed with pride (aka stolen) from newsgroup
postings, web sites, mail lists and various elisp repositories. As I
tend not to bother compiling my init, you would not necessary be aware
of obsolete and deprecated functions used by this code. The lack of any
namespace for packages also meant name conflicts were sometimes the
cause of weird bugs etc. Overall, things were 'fragile' and you would
avoid making changes as much as possible.
I was frequently surprised when I decided it was time to cleanup my init at
various improvements and enhancements that had been added to Emacs. This
is partially a result of the conservative approach Emacs tends to adopt
- a good approach as it means you can usually upgrade to a new version
and not end up spending hours fixing things just to get back to
work. However, the downside is that it also means you may not even be
aware of or benefit from some improvements.
The positive is that now I have a nicely structured and documented org
file with my init and making changes is easy. Actually, I have multiple
configs - a standard working config, a 'new features' config where I try
out new packages etc, a very simple minimal config I use for
testing/debugging problems etc. I have a simple shell script which I can
run and pass it an org file name which will generate a new init.el and I
keep it all in git. At this time, I'm probably happier with my Emacs
setup than during any period in the last 25 years.
Tim
Tim Cross
prev parent reply other threads:[~2018-10-26 21:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-21 0:36 electric-pair, autopair, smartparens, etc in org-mode Matt Price
2018-10-21 7:28 ` Nicolas Goaziou
2018-10-21 16:43 ` Matt Price
2018-10-23 7:58 ` Roland Everaert
2018-10-23 11:48 ` stardiviner
2018-10-23 13:07 ` Eric S Fraga
2018-10-24 13:12 ` Matt Price
2018-10-24 14:15 ` Eric S Fraga
2018-10-24 10:38 ` Roland Everaert
2018-10-24 10:45 ` Eric S Fraga
2018-10-24 21:24 ` Tim Cross
2018-10-25 15:07 ` Eric S Fraga
2018-10-25 22:57 ` Samuel Wales
2018-10-25 22:59 ` Samuel Wales
2018-10-26 9:23 ` Eric S Fraga
2018-10-26 21:45 ` Tim Cross [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87efccl6uw.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=reveatwork@gmail.com \
--cc=samologist@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).