emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Emacs-orgmode Digest, Vol 185, Issue 7
Date: Wed, 07 Jul 2021 09:20:25 +1000	[thread overview]
Message-ID: <878s2jlzi2.fsf@gmail.com> (raw)
In-Reply-To: <8b7d39a2-dcc7-4134-9adc-08ed2477cc6b@gmail.com>

Ypo <ypuntot@gmail.com> writes:

> Hi
> Several things around my mind. Pick one if you like, and I will try to explain it better.
> - when using ediff, if there is an image near the text which has differences, it
> works wrong. Like if the image wouldn't allow ediff to scroll and show the
> difference. I just see the image, stationary, while jumping to the next
> difference.

I'm not sure how well ediff supports diffs containing things like
images. The ediff program (which is not part of org-mode, only used by
org mode) is designed for showing the differences between buffers of
text and to help with merging such differences. I'm actually surprised
ediff even displays images. 

> - I have started to read Chassell's. Introduction... to Emacs Lisp. But my ideas
> grow much much faster than my reading. I even feel I won't be able to implement
> simple ideas in years. Example: I would like that every time "I see" a heading
> with a special TODO state, this heading is expanded. Should I keep reading the
> book to materialize this little idea or should I take different actions?

Definitely keep reading the book and spend some time writing some elisp
code to do simple things. A basic understanding of Emacs lisp is
extremely valuable. Although the functional style of lisp based
languages can seem confusing at first, it is actually very simple. There
is only a small amount of syntax to learn, but it can take a bit of time
to start thinking in a 'functional' paradigm. Probably the hardest part
to learn is all the terminology for things like point, mark, buffers,
region and the wealth of functions provided by core elisp libraries.
Make sure you spend time getting to understand the Emacs help system and
the info manuals. This is critical and one of the key powers of Emacs -
you can explore and find functions easily and get the documentation with
just a few key strokes. 

With org mode, and with Emacs generally, often your best course of
action is to be patient and avoid customising the system initially.
Emacs and to some extent, org mode, is complex, often uses weird terms
for things and incorporates new approaches and ways of doing things
which can seem very odd at first. The normal response is to try and
change things to be more familiar and make the experience more similar
to what you are use to. This is often a mistake.

Those who take the time to really experience the way both Emacs and org
mode work often find there are significant benefits to the Emacs and org
approaches over what they are use to. These differences are not always
obvious initially and it is only once you have been using them for a
while you recognise some of the more subtle benefits.

I think it is good to realise that while we are all different, what we
require in our editor is remarkably similar. Emacs is a program with a
very large user base and which has been around for many decades. It is
highly likely when you come up with an idea someone else has already had
one which is very similar. I have lost count of the number of times I've
thought "I wish emacs could do xxxx' only to later find that not only
could it do it, the feature already exists and is even more refined and
powerful than my original idea. The challenge with Emacs is often just
finding that feature or recognising it. After using Emacs for nearly 30
years, I am still discovering stuff and refining my configuration. I
frequently learn about things in forums, blog posts, videos and other
sources which either give me ideas, help me refine my setup or introduce
me to something new. The amount of custom elisp code I have has actually
reduced over the years as I find existing better ways to do things than
my horrible elisp hacking. 

A common error, one which I made myself, is to initially be really
impressed by the possibilities org mode offers and immediately start
customizing things to realise some of the great ideas it has generated.
However, this is often a mistake. It can result in over engineering and
workflows which are overly complex and to some extent self defeating. In
many cases, you end up partially re-inventing wheels which already
exist, but which perhaps look slightly different to how you conceived
them (which makes them difficult to recognise). Often the differences
are because org's approach is more refined or deals with other related
issues you have not seen or yet identified.

When starting with org mode, the best approach is to only do as little
configuration as you need to get things working. Avoid defining new todo
states, capture templates, adding custom hook functions etc until after
you have used org mode for a time and have become familiar with what
features it provides and its approach to organising information. Often,
this will expose you to new ways of doing things which are actually
better. You will also often find that org or Emacs already implements
some feature you would like, but called something you did not expect or
implemented in such a way it was not easily recognised at first. 

Once you are more familiar with how org works and understand the
features it offers, you will often realise your original ideas and
workflows were in many ways flawed and can be refined and improved using
just available features. There will be things you will eventually want
to customise and enhance to make your environment meet your needs, but
wait until your more familiar with both org and Emacs and what it has to
offer. By doing this, you will often find new and more efficient
approaches and know how to combine existing features more efficiently. 

> - when I export to latex, I get an error and no document is produced. Sorry I
> can't share here the error, since I am writing from the mobile, but it seems
> related to xelatex. Buuut, if I take the .tex produced file and I open it with
> an external latex editor, the document is compiled into a decent PDF. How could
> orgmode generate a valid tex document but not to be able to produce its PDF?

Latex is a powerful, but somewhat complex, system. There are many
different latex compilers offering slightly different feature sets. Org
mode is configured by default with fairly sane defaults, but these are
not necessarily ideal for all situations. For example, org uses the
pdflatex compiler to generate PDF files from the *.tex sources generated
by org (see the documentation for org-latex-pdf-process). You appear to
be manually generating the documents using xelatex, which org does not
use by default. Try compiling your *.tex document using pdflatex and you
may get more informative errors that will help you get things
configured. Look at the org manual and org wiki to get more information. 

Providing the exact error message is critically important if you want
some useful assistance. Without the precise error message, we are
largely in the dark and can only guess at what is causing your issue. In
fact, when reporting an issue, you are far more likely to get help and a
speedy resolution if you can provide a minimal recipie to reproduce your
problem. This will often include a sample org file and a clear recipe to
reproduce the issue.

> - some more bugs I found, I should share from the PC.

It is more likely the issues you are running into are due to either
missing dependencies (such as key latex packages used by org) or local
configuration errors in your setup. Org has a very large user base and
while we do see regular bug reports, these tend to be bugs related to
quite advanced features. They tend to be bugs which only show up in less
common edge cases or they are due to misconceptions held by the user who
is expecting one thing and getting something different.

For example, the fact you cannot generate PDF files when exporting an
org document is highly unlikely to be a bug. Generating PDFs from org
files is something done many times a day by hundreds (thousands?) of org
users. If there were many bugs in this process, we would be seeing
thousands of bug reports. Your report of not being able to generate PDF
files is the first such report I've seen in quite some time and all the
more recent ones I've seen have been due to configuration errors or
missing dependencies. There have been recent reports relating to
problems with very advanced features, but it is unlikely you are using
any of these at this point.

With programs like Emacs and org mode, which have a very large user
base, your best off initially considering any errors you encounter to be
due to a local issue in your setup. For people to provide assistance
with your issues, we need to understand your configuration. To assist
with this, org-mode provides the function 'org-submit-bug-report', which
will create an email buffer with details about your org and emacs setup
which will make it easier to try and reproduce your issue and provide
assistance. If you use Emacs for your email, you should be able to
update this buffer with specifics about the issue you have or copy and
pase the contents of the buffer into your normal email program. See the
section on reporting bugs in the org manual for full details. 

Tim Cross

  parent reply	other threads:[~2021-07-07  0:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.57.1625587206.4137.emacs-orgmode@gnu.org>
2021-07-06 21:28 ` Emacs-orgmode Digest, Vol 185, Issue 7 Ypo
2021-07-06 21:34   ` Samuel Banya
2021-07-06 21:38   ` Samuel Banya
2021-07-06 23:20   ` Tim Cross [this message]
2021-07-07 12:11   ` Eric S Fraga

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:

  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=878s2jlzi2.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* 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


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).