Re: org-babel not finding executables when using direnv [Was: Re: ob-sql is not finding psql when using direnv+guix]

2021-05-13 Thread Tim Cross


"Adolfo De Unanue"  writes:

> On Wed, May 12, 2021, at 08:49, Cook, Malcolm wrote:
>> > > >I am using Guix with direnv.
>> > > 
>> > > What is your shell?
>> > > 
>> > 
>> > My shell is bash, originally I was using zsh and I thought that was the
>> > problem, so I switched to bash and still not working.
>> > 
>> > > How/When do you "hook direnv into your shell" (https://direnv.net/)?
>> > > 
>> > 
>> > In the .profile file, at login.
>> > 
>> > > > In an specific folder I am installing and using psql and postgresql 
>> > > > using direnv+guix as follows:
>> > > >use guix --manifest=cdpp-manifest.scm
>> > > >
>> > > >export PGUSER=food_user
>> > > >export PGPASSWORD=some_password
>> > > >export PGDATABASE=food
>> > > >
>> > > >layout postgres
>> > > 
>> > > When are you doing this?
>> > > 
>> > > a) in the "specific folder"'s .envrc file?
>> > > b) in an org-mode shell block that you execute prior to the sql block?
>> > > c) ??
>> > 
>> > Option (a)
>> > 
>> > 
>> > > You seem to be following [Per\-project 
>> > > Postgres](https://jamey.thesharps.us/2019/05/29/per-project-postgres/) 
>> > > but with guix instead of nix. Nice.
>> > > 
>> > 
>> > Yep, great post. direnv + guix change the way I develop software, do data 
>> > science and write lectures and papers.
>> > 
>> > > If you enter the directory and then call emacs, earthing should just 
>> > > work, no changes neede.
>> > > 
>> > 
>> > It works for almost everything (sql-buffers, python buffers, etc), except 
>> > for org-babel sql blocks.
>> > 
>> > I am using EXWM, so emacs is always on.
>> > 
>> > 
>> > > If you want to tell emacs to adopt the environment established by a 
>> > > .direnv, you probably want [direnv integration for 
>> > > emacs\.](https://github.com/wbolster/emacs-direnv)
>> > > 
>> > 
>> > emacs-direnv was my first choice, but then I changed to envrc
>> > (https://github.com/purcell/envrc) . In both I got the error.
>> > 
>> 
>> I see.  Envrc looks superior.  Good to know.
>> 
>> You've covered all my bases.  Shooting in the dark,  I would 
>> confirm/check the following:
>> 
>
> I have news:
>
> It fails for python too. Using the same files as before and this block:
>
> #+begin_src python 
> import pandas as pd
> import matplotlib.pyplot as plt
> #+end_src
>
> It finds matplotlib, but fails to find pandas. I tried the same trick as 
> before
> (but with the python executable, no psql), added the line
>
> (org-babel-python-command . ".direnv/.guix-profile/bin/python3")
>
> but is not working. 
>
> But if I am in shell, or in a python buffer or in a inferior-python process
> Emacs is finding all the libraries and executables.
>
> So, I am assumming that the problem lies in how org-babel searchs the path ...

This is very unlikely. If there were issues in this area, we would be
seeing many more bug reports. More likely is that the PATH variable
doesn't contain what you think it does. First thing I would do is try
running the following source block

+being_src emacs-lisp
  (getenv "PATH")
+end_src

and verify the direnv bin directory is actually in your path.

Emacs will inherit the path from the shell running when emacs is
started. Changes made in your shell after Emacs has started will have no
effect on the PATH variable for emacs.

You mentioned at one point your running exwm. If you are not running
exwm in a login shell and your not sourcing your ~/.profile prior to
starting Emacs/exwm (assuming the direnv settings and path are setup
there), then the path variable is not going to have the direnv bin
directory. Either you need to ensure the appropriate direnv bin
directory is in your path before starting exwm or you need to add a
configuration step (e.g. possibly a hook function) which will add the
direnv bin directory using setenv.



-- 
Tim Cross



Re: [PATCH] Fontification for inline src blocks

2021-05-12 Thread Tim Cross


Timothy  writes:

> Thank you for the detailed feedback :)
>
> Ihor Radchenko  writes:
>
>> Timothy  writes:
>>
>>>> I do not like abusing prettify-symbols-mode. What if it is not enabled?
>
> If you know of another way of accomplishing text-replacement which
> changes back when the cursor enters the region, please let me know.
>
>>> Ah, it does it anyway at the moment.
>>
>> Hmm. You are right. You are calling compose-region directly. Note, that
>> you do not add 'decompose-region function for automatic region
>> destruction (see help:pretty-symbol-pattern-to-keyword).
>
> Isn't the same effect achieved by the remove-list-of-text-properties call?
>
>> If I understand correctly (I did not really install your patch), if you have
>> composed region, disable font-lock, and try to edit the region, edits
>> will be invisible. Or imagine setting org-inline-src-prettify-results to
>> nil in already fontified buffer.
>
> I just tried "setting org-inline-src-prettify-results to nil in already
> fontified buffer." and the region just decomposed and stayed that way.
>
>> Also, you may find help:font-lock-extra-managed-props useful. That way,
>> you will not have to manually remove composition and other non-standard
>> properties during fontification
>
> Hmmm, from a look I can't tell exactly how these are "managed". Are they
> just removed when a region is processed?
>
>> why are you even removing 'face? It should be already done by font-lock).
>
> I tried removing such calls, and everything still worked, so this is no
> longer done.
>
>>>> What will happen if user toggles prettify-symbols-mode in Org buffer?
>>>
>>> This seems to be toggled nicely by prettify-symbols-mode too.
>>
>> I would not expect it to. Why would prettify-symbols-mode interfere with
>> Org mode native fontification if it is not strictly necessary?
>
> Well, I guess this is a by-product of using prettify-symbols-start/end,
> see my note at the start of this email about not being aware of anything else.
>
>> P.S. Nitpick: You do not need to run fontification in while loops. Just
>> fontifying next match before limit should be enough. Font-lock will call
>> the function again if needed.
>
> I'm guessing for this to work I'd need to return the final char
> fortified? Or is the moving of point enough?
>
> Maybe related - I've noticed this doesn't seem to work with multiple
> src_ blocks per line, might you have any insight here?
>
>
This may or may not be something to consider but ...

What is the impact of using this technique for accessibility and users
of assistive technology like text-to-speech or braille displays?

I'm currently not in the position to test this patch, but once I get
some environments for testing sorted out, I should be able to try it
out.

>From an accessibility perspective, behaviour which changes what is
'displayed' based on cursor position is often confusing for things like
text-to-speech. In the past, I have run into issues with prettify
symbols because it results in either less meaningful content (e.g.
unicode numbers rather than defined character names) or additional
spoken text which makes it difficult to understand. Things like
overlays, tooltips or features which make display different from
underlying character content can often be problematic with assistive
technology. 



-- 
Tim Cross



Re: URLs with brackets not recognised

2021-05-12 Thread Tim Cross


Rudolf Adamkovič  writes:

> Maxim Nikulin  writes:
>
>> I do not think it is a bug. Plain text links detection is a kind of
>> heuristics. It will be always possible to win competition with regexp. 
>> Consider it as a limitation requiring some hints from an intelligent
>> user.
>
> I disagree. URLs are well-specified. Per RFC 3986, the characters
> allowed in a URL are [A-Za-z0-9\-._~!$&'()*+,;=:@\/?]. Org mode should
> implement proper URL detection, not asking its users "to give it some
> hints" and using "a kind of heuristics". A string either is a valid URL
> per the relevant RFCs or it is not.
>

Limitations with plain text links are documented in the manual, with an
explanation of why you need to use the org link insertion commands to
created a valid link which escapes the problematic characters.

As this is defined and documented behaviour, I don't see how it can be
considered a bug. You might consider it a frustrating or even
unnecessary limitation, but not a bug.

I'm sure a patch which improves org handling of plain urls would be
considered. However, previous attempts at such enhancements have either
resulted in significant performance impact or unexpected and unwanted
side effects. In short, this is a non-trivial problem to solve. As the
need for such use cases in plain text links is a small use case and as
you can have those links using org link syntax, it would be very hard to
justify a patch which may have adverse performance impact for all users. 

This change could be considered a feature enhancement, but it is not a
bug.

-- 
Tim Cross



updates.orgmode.org giving 502 Bad Gateway Error

2021-05-12 Thread Tim Cross


FYI the updates.orgmode.org page is giving a 502 Bad Gateway error when
I try to access it.

-- 
Tim Cross



Re: Q: ox-md does not translate link searches to #bookmarks in markdown [9.4.4 (release_9.4.4 @ /snap/emacs/current/usr/share/emacs/27.2/lisp/org/)]

2021-05-11 Thread Tim Cross


Phil Marneweck  writes:

> Hi
>
> Is this by design? 
>
> I expected to following
>
> [[file:some-file.org::#some-heading][some text]] 
>
> to translate to this
>
> [some text](some-file.md#some-heading)
>
> So in org-md-link I would have thought that the default would be more like 
> this
>
> (t (if (not desc) (format "<%s>" path)
>  (format "[%s](%s%s)" desc path (or (org-element-property :search-option 
> link) ""
>
> You would of course have to do some sanity checking on search-option to just 
> take care of id versus headline searches etc.
>

I'm not sure if this is by design or because of limitations in the
markdown dialect used by org mode (see
http://daringfireball.net/projects/markdown) or just a bug. My
suspicion, after a quick review of the markdown syntax on the
daringfireball site is that search links are not supported.

This is one of those examples of the problems arising from a format type
which does not have a specification. There are numerous different
markdown dialects and org had to select one. Problem is, everyone gets
use to a particular dialect and then is often disappointed when org's
dialect does not match their expectations. One reason we also have the
github flavoured markdown exporter.


-- 
Tim Cross



Re: The fate of ditaa.jar (9.4.5.)

2021-05-11 Thread Tim Cross


TEC  writes:

> Tim Cross  writes:
>
>> I also had to install textlive, plantuml, graphviz, taskjuggler,
>> ledger, sqlite and many other things.
>
> Perhaps it would be good to make a table of
>
> | software | needed for | package name | download page |
>
> and/or prompt users when an action requiring another executable is
> undertaken if it isn't found.

Useful additional documentation, assuming it can be maintained, is
rarely a bad idea. A table on worg (with maybe a link in the manual)
which lists all the org (and contrib) features, external dependencies
and link to canonical source would probably be a good idea.

I find it hard to remember how I worked out all the dependencies as I
adopted org as it was so long ago and I was already a heavy user of
many of the tools/dependencies of org. This makes it challenging to
appreciate how hard it can be for someone knew to org. On the other
hand, if we make it overly easy/automatic, we run the risk of
disempowering the user and making them more dependent on assistance from
others. Finding the right balance between informative and concise is a
challenge. If we provide too much information, it can be overwhelming,
too little and it can be confusing. I find it harder to write good
documentation than good code!


-- 
Tim Cross



Re: (void-variable timestamp-up) when building an agenda buffer

2021-05-11 Thread Tim Cross


Alan Schmitt  writes:

> [[PGP Signed Part:Undecided]]
> Hello,
>
> It seems the problem is deeper than that: I cannot use any code that
> uses =org-dlet=… I’m on emacs 27.2.
>
> I did a quick test with no configuration, so the problem seems to be in
> my config, but I’m cursious if this rings a bell for anyone.
>
> Thanks,
>

The type of error you appear to be seeing is common with a broken
install. In your config, are you installing org from orgmode.org or
melpa rather than just using the version bundled with Emacs 27.2? If so,
it is likely that you have a 'mixed' install. This can happen if org is
loaded when you try to install or update the org version. A common
problem is not realising that something in your init file is causing org
to be loaded during startup - then when you try to do a package update,
you get a broken build.

If your not installing org from a package, then it is likely something
else in your init file and unfortunately, you may have to do the painful
bisecting and debugging to find the cause. 

-- 
Tim Cross



Re: The fate of ditaa.jar (9.4.5.)

2021-05-11 Thread Tim Cross


"Dr. Arne Babenhauserheide"  writes:

> [[PGP Signed Part:Undecided]]
>
> Tim Cross  writes:
>> I agree. As pointed out already, just bundling the jar file is not
>> sufficient as you need a java runtime as well.
>
> Java is available in my distribution, ditaa is not. Removing ditaa from
> org means that I have to do manual installation and configuration, while
> with ditaa bundled, org-mode can simply note that I need java installed.
>

I get that. However, this is of course not the case for many users (Mac,
Windows). Having to install additional software to realise org
functionality is normal for much of org-mode. In fact, I had to install
ditta when I first used it because it wasn't bundled. That was not an
issue and no surprise given I also had to install textlive, plantuml,
graphviz, taskjuggler, ledger, sqlite and many other things.

I understand the convenience for users argument. However, I think we
also need to consider the maintenance overheads and consistency aspects
as well (including dealing with bug reports when it doesn't work). 

>> If we bundle it, we also need to ensure it is updated if/when new jar
>> versions are released.
>
> We can do that, but we don’t have to. As long as the bundled jar works,
> it is much better than no jar. And users can use newer version as they
> like by changing the jar-path.
>
> Note that this isn’t about security, since even if an old version of
> ditaa should turn out to be vulnerable, this would still be less
> dangerous than a shell-block. Therefore old versions of ditaa are
> completely fine.
>

My thoughts were more about bugs and confusing deprecation warnings
which can arise when using an older jar file with a more recent jre.

Ultimately, it will fall to whoever steps up to maintain ditta support
to decide. 

-- 
Tim Cross



Re: Highlighting and Background Colour for Source Code

2021-05-11 Thread Tim Cross


Christopher Dimech  writes:

>> Sent: Tuesday, May 11, 2021 at 4:50 PM
>> From: "Tim Cross" 
>> To: emacs-orgmode@gnu.org
>> Subject: Re: Highlighting and Background Colour for Source Code
>>
>>
>> Christopher Dimech  writes:
>>
>> > Currently currently handles the highlighting of programming languages 
>> > through
>> > "Code Blocks".  Could org-mode have the capability of highlighting a whole 
>> > buffer
>> > with a particular language highlight typeface.
>> >
>>
>> Sorry, I don't quite understand what exactly your asking for?
>
> Suppose I have an elisp file and I change to org-mode by hitting "M-x 
> org-mode".
> The code does not get highlighted because it is not embedded within org-babel
> construct.
>
> If I have a programming language file with some org-mode heading commands in 
> it,
> and change to org-mode, it would be neat to have language highlighting 
> available.
>

OK, now I think I understand.

Basically, with full org-mode, this is not possible and I don't think it
is actually want you want. Once you switch modes, say from elisp mode to
org mode, a lot more changes than just the font locking. Keybindings,
various support minor modes and lots more.

The 'normal' Emacs way to handle what you are looking for is to add a
minor mode. A minor mode is used to add some level of functionality to a
buffer without losing the major mode settings. Normally, you only have
one major mode associated with a buffer and often that mode is augmented
with a bunch of minor modes. For example, outshine mode is a minor mode
which adds some org-like functionality to non org-mode buffers.

Have a look at

https://orgmode.org/worg/org-tutorials/org-outside-org.html

I think that might give you some ideas to get you started. You may need
a few different minor modes to get the full setup you want and you will
likely need to do some customisation of key bindings etc to get things
how you like it. 

-- 
Tim Cross



Re: Highlighting and Background Colour for Source Code

2021-05-10 Thread Tim Cross


Christopher Dimech  writes:

> Currently currently handles the highlighting of programming languages through
> "Code Blocks".  Could org-mode have the capability of highlighting a whole 
> buffer
> with a particular language highlight typeface.
>

Sorry, I don't quite understand what exactly your asking for?

> I have also seen that within code blocks, the background is uses a colour 
> that is
> different from the background colour of the buffer.  Is there a capability 
> that
> the code block background is set to the buffer background colour.

I think more often than not, this is determined by the Emacs colour
theme your using. I've noticed that some themes colour src block
backgrounds differently from the rest of the buffer background and some
don't. I noticed this because I do like src blocks to have a different
background and some of the themes I like fail to do this, so I had to
customize them. 

You can try customizing your theme. Have a look at 

M-x list-colors-display

to see a list of all the faces being used. Look for ones with your theme
name or a name which looks like it might be the background face for src
blocks (you can also see the colours and look for that. Once you have
made the changes, look at 

M-x customize-theme

and save your changes as a new customized theme.



-- 
Tim Cross



Re: The fate of ditaa.jar (9.4.5.)

2021-05-10 Thread Tim Cross


Nick Dokos  writes:

> Jarmo Hurri  writes:
>
>> Greetings.
>>
>> I pulled the latest master and noticed that contrib has been moved into
>> a separate repository. I also cloned this contrib repository, but can
>> not find the file
>>
>> scripts/ditaa.jar
>>
>> in the repo. In fact, there is no directory scripts in the repo.
>>
>> The documentation in the latest master states that
>>
>> Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now
>> packaged into the org-contrib repository.
>>
>> How should I proceed? Should I build this separately
>>
>> https://github.com/stathissideris/ditaa
>
> You don't need to build it: it's available in the release area
>
> https://github.com/stathissideris/ditaa/releases
>
>>
>> or will it still be included into contrib?
>
> In general, I think it's a better idea to point to the canonical sources
> and document how to integrate it into Org mode, than bundle things like
> that, but I have no idea how things are going to go. I'm sure there will
> be some problems that will need fixing one way or another.

I agree. As pointed out already, just bundling the jar file is not
sufficient as you need a java runtime as well. If we bundle it, we also
need to ensure it is updated if/when new jar versions are released. 

Better to clearly document where to get the dependencies and point to
the appropriate installation instructions.

I think we also need to keep in mind that we are currently in a bit of a
transition stage with the move to using ELPA and non-gnu ELPA. There
will be teething problems needing to be worked through both before and
after the transition. 
-- 
Tim Cross



Re: [PATCH] A proposal to add LaTeX attributes to verse blocks

2021-05-03 Thread Tim Cross


Timothy  writes:

> Eric S Fraga  writes:
>
>> Is the verse package loaded automatically already?  I did not see any
>> change in the patch to that aspect and when I export a simple test, the
>> package is not loaded.
>
> Wouldn't it be nice if there was something in-between loading the
> kitchen sink and manually adding packages*... [ foreshadowing ;) ]

Will be interesting to see what you are 'foreshadowing'.

Personally, I find the current options pretty flexible with
'org-latex-classes and support for the macro like placeholders
[PACKAGES, DEFAULT_PACKAGES, EXTRA and their negators] and the ability
to add packages with LATEX_HEADER and LATEX_HEADER_EXTRA file options.
I'm often quite surprised how little people seem to take advantage of
'org-latex-classes and the LATEX_CLASS; file option to define custom
document formats. You can easily define an 'empty' class which only
includes packages you add with LATEX_HEADER: or LATEX_HEADER_EXTRA for
example. 

It is with 'tweaking' Latex packages I've seen people get into trouble.
There can often be some unexpected results when you fail to load or load
packages in a different order. Testing is notoriously difficult as you
also need a lot of different test input data to get good coverage and
adequately test the impact changes to loaded Latex packages causes.
Without detailed knowledge of the latex based exporters, it isn't always
obvious how/where specific Latex packages are used. It would be
important to ensure any mechanism designed to make it easier to
customize what packages are loaded that we don't also end up generating
more bug rports about broken export formatting. 

-- 
Tim Cross



Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

2021-05-03 Thread Tim Cross


Bastien  writes:

> Hi all,
>
> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation
>
> I suggest a criterium for keeping ob*.el files in Org could be that
> the extension is known by Emacs _or_ that the supported language is
> well-established.
>

+1 on this and the list of proposed languages.

Do any of these ob-* files have FSF copyright i.e. author assigned
copyright to FSF. Just wondering, given the contrib package will live in
non-gnu repo, if this is something we need to be concerned about or not?

Strikes me there is nothing written in stone here, so if a language
becomes popular and it has maintainers, we can always review the
decision to move it 'out' and when justified, move back into core.

I think it is good having a clear distinction and the idea that if your
using a contrib package, it is 'best effort only' and not guaranteed to
work with the most recent org version compared to 'core', which has an
expectation it works with most recent org version.

-- 
Tim Cross



Re: [POLL] Setting `org-adapt-indentation' to nil by default?

2021-05-02 Thread Tim Cross


Jean Louis  writes:

> * Tim Cross  [2021-05-02 11:52]:
>> 
>> Jean Louis  writes:
>> 
>> > * Bastien  [2021-05-02 09:10]:
>> >> Various discussions convinced me that `org-adapt-indentation' should
>> >> be nil by default.
>> >> 
>> >> With `electric-indent-mode' being activated by default in Emacs, the
>> >> current behavior is that RET after a headline moves the point below
>> >> the beginning of this headline, not the beginning of the line, which
>> >> might surprise users.
>> >> 
>> >> Indentation is quite sensitive: what do you think of setting a new
>> >> default value of nil for `org-adapt-indentation' in Org 9.5?
>> >
>> > Yes, it should be nil just as it was in beginning.
>> >
>> > But there is one problem that I encountered since that was introduced,
>> > namely I do like properties being indented under the first letter of
>> > heading or on 3rd place.
>> >
>> > Like this below, however, C-c C-x p will create properties indented
>> > only if org-adapt-indentation is t
>> >
>> > * Heading
>> >   :PROPERTIES:
>> >   :ARCHIVE:  new
>> >   :END:
>> >
>> > But if org-adapt-indentation is nil, it will be like:
>> >
>> > * Heading
>> > :PROPERTIES:
>> > :ARCHIVE:  new
>> > :END:
>> >
>> > and I remember that behavior before the introduced change was that
>> > properties were intended, which does look nicer for properties.
>> >
>> > But I definitely do not prefer cursor to come indentend after writing a 
>> > header like:
>> >
>> > * Heading
>> >   C
>> >   ursor on C
>> >
>> >
>> 
>> Sounds like you want the 'headline-data value for this variable. Please
>> check the documentation.
>
> If I set `org-adapt-indent' to 'headline-data, I get that same
> behavior that after pressing ENTER on headline line, position becomes
> indentend. So it does not make it right.
>
> My favour was the behaviour how it was before introduction of
> indentation change:
>
> - after headline, cursors went to beginning of line; I find it
>   usable, as that is where I write text. 
>
> - if I ever wanted to enter properties with C-c C-x p, those were 
> automatically
>   indented,
>
> But OK I can personally get used, especially that I these months avoid
> using any properties in Org mode.
>
>
> "GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 
> 1.17.4, Xaw3d scroll bars)
>  of 2021-05-02"

This is  exactly what headline-data does. I suspect what your running
into is electric-indent-mode and you need to turn it off to get the
behaviour you want. So set org-adapt-indentation to hedline-data and
turn off electric-indent-mode and you will get the indentation style you
are after.

The issue here isn't that org-adapt-indentation changed. The issue is
that the effect of this setting changed when org mode was updated to be
consistent with the rest of emacs and honour electric-indent-mode, which
is enabled by default in emacs. Previously, org ignored this wider Emacs
default setting.

The poll is to decide if we should change this long standing default due
to the side effects from enabling electric-indent-mode. Enabling
electric-indent-mode was done to make org mode consistent with other
Emacs modes, so disabling it by default would be inconsistent with Emacs
defaults. 

I'm not sure the full impact of enabling electric-indent-mode was
realised at the time. With org, I think the general principal is to try
and have defaults set to the 'least surprising' value, particularly for
new users. 
-- 
Tim Cross



Re: [POLL] Setting `org-adapt-indentation' to nil by default?

2021-05-02 Thread Tim Cross


Jean Louis  writes:

> * Bastien  [2021-05-02 09:10]:
>> Various discussions convinced me that `org-adapt-indentation' should
>> be nil by default.
>> 
>> With `electric-indent-mode' being activated by default in Emacs, the
>> current behavior is that RET after a headline moves the point below
>> the beginning of this headline, not the beginning of the line, which
>> might surprise users.
>> 
>> Indentation is quite sensitive: what do you think of setting a new
>> default value of nil for `org-adapt-indentation' in Org 9.5?
>
> Yes, it should be nil just as it was in beginning.
>
> But there is one problem that I encountered since that was introduced,
> namely I do like properties being indented under the first letter of
> heading or on 3rd place.
>
> Like this below, however, C-c C-x p will create properties indented
> only if org-adapt-indentation is t
>
> * Heading
>   :PROPERTIES:
>   :ARCHIVE:  new
>   :END:
>
> But if org-adapt-indentation is nil, it will be like:
>
> * Heading
> :PROPERTIES:
> :ARCHIVE:  new
> :END:
>
> and I remember that behavior before the introduced change was that
> properties were intended, which does look nicer for properties.
>
> But I definitely do not prefer cursor to come indentend after writing a 
> header like:
>
> * Heading
>   C
>   ursor on C
>
>

Sounds like you want the 'headline-data value for this variable. Please
check the documentation.

Note that there was a bug with this setting which has recently be fixed.
So if you tried it previously and found it didn't quite work correctly,
try it again in current maint version.





Re: [POLL] Breaking change: removing `org-speed-commands-user'

2021-05-02 Thread Tim Cross


Bastien  writes:

> As discussed in https://orgmode.org/list/87v9hzzhrn@gmail.com the
> proposal is to allow users to customize *all* speed keys, not just
> some of them through `org-speed-commands-user'.
>
> By merging `org-speed-commands-default' and `org-speed-commands-user'
> into a single `org-speed-commands' option, we make this possible, but
> this change will ignore people's `org-speed-commands-user' config, so
> this is a breaking change.
>
> Do you think this change could be too sensitive for users? 

I don't really have a position on this. However, my 'gut' tells me that
anyone who has used org-speed-commands-user will be able to adapt to the
change without too much inconvenience. A clear NEWS entry will help.


-- 
Tim Cross



Re: [POLL] Setting `org-adapt-indentation' to nil by default?

2021-05-02 Thread Tim Cross


Bastien  writes:

> Various discussions convinced me that `org-adapt-indentation' should
> be nil by default.
>
> With `electric-indent-mode' being activated by default in Emacs, the
> current behavior is that RET after a headline moves the point below
> the beginning of this headline, not the beginning of the line, which
> might surprise users.
>
> Indentation is quite sensitive: what do you think of setting a new
> default value of nil for `org-adapt-indentation' in Org 9.5?

+1. I think it will be less surprising for users and those who want that
type of indentation can easily enable it.

-- 
Tim Cross



Re: Bug: First file opened does not colorize (tested with 9.3.7 and 9.4.5)

2021-04-30 Thread Tim Cross


What about running emacs -Q and then opening the org file. Does the
syntax highlighting work then?

Dominick Samperi  writes:

> Changing the suffix to .org does not help. Still the first file opened
> does not colorize.
> I first observed this problem about six months ago (and have been
> using a function
> key to fix with 'org-mode-restart).
>
> The problem does not appear on a new desktop, running
> the same version of Emacs, same version of org-mode, and same .emacs.d.
>
> The only notable difference between the new machine and the older machines
> where the problem occurs is that the newer machine has an solid state drive,
> whereas the other machines have conventional hard drives.
>
> On Fri, Apr 30, 2021 at 8:51 PM Samuel Wales  wrote:
>>
>> what if .org?
>>
>> On 4/30/21, Dominick Samperi  wrote:
>> > The first org mode file opened (.txt suffix) is not colorized. To force
>> > colorize I use 'org-mode-restart. Subsequently opened txt files are
>> > properly colorized. This happens under Windows 10 using Emacs 27.1 and
>> > 27.2, and org-mode 9.3.7 and 9.4.5. There are no problems under Ubuntu
>> > Linux.
>> >
>> > Oddly, the problem does not appear on my new desktop (Lenovo). It
>> > happens on my ASUS laptop. I'm using the same version of org-mode and
>> > Emacs on both machines.
>> >
>> > I copied .emacs.d from the desktop to the laptop
>> > to be sure the environments are the same, and I installed Emacs 27.1
>> > and 27.2 on the laptop. The colorize problem occurs on the laptop no
>> > matter the environment. It also occurred with my old desktop.
>> >
>> >
>>
>>
>> --
>> The Kafka Pandemic
>>
>> Please learn what misopathy is.
>> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html


-- 
Tim Cross



Re: stability of toc links

2021-04-30 Thread Tim Cross


Nicolas Goaziou  writes:

> Hello,
>
> Samuel Loury  writes:
>
>> The publish feature only means exporting several files at once. 
>
> You can publish a single file, too. It makes sense when a file is always
> exported to the same location, possibly with the same configuration.
>
>> IIUC, what was written was that when using the publish feature, the exported
>> html pages will be coherent and a link in one document pointing to
>> another document of the same publish call won't be broken.
>>
>> But IIUC, publishing the whole stuff again will result in totally
>> different links. They will still be coherent and no broken link from one
>> document of the whole to another. But a browser bookmark pointing the
>> published lot the first time won't work with the same lot the second
>> time.
>>
>> Did I understand correctly?
>
> That's correct. 
>
> Org provides a mechanism, called `org-export-get-reference', for
> creating internal references, which relies on randomness + cache. But it
> explicitly removes internal references not actually used from there (see
> `org-publish--store-crossrefs'). Keeping those references instead would
> make all links stable, of course.
>

Given this is not the first time we have seen a similar discussion
regarding link stability for external references, perhaps it would be
good to summarise and put it on worg for reference?

First attempt - let me know if I've got it close!

- If you need stability in TOC links between generated versions, use
  Org's publish facility rather than plain HTML export.

- Publish can be used to publish a single file.

- 'something' in the published output needs to reference the TOC links
  to ensure consistency.

HTML export lacks the internal caching/tracking necessary to have
internal link consistency across exported versions. Adding such
capability would significantly complicate the HTML export code base.
This is hard to justify when this export facility is also used for
things like HTML fragments and because internal link stability is only
required in a sub-set of use cases.

The org publish facility already includes the necessary internal
facilities to support internal link consistency across published
versions. You can use publish to publish a single file. Currently, the
internal links need to be referenced/used in order to ensure consistency
across published versions.

If stability of TOC links across versions is required, using publish is
the preferred mechanism. If we would want to make it easier for the user
to create published pages with consistent internal TOC links, we would
be better off enhancing the publish mechanism rather than trying to add
such facilities to the HTML export function. 

-- 
Tim Cross



Re: Big problem: org agenda freezes my process

2021-04-30 Thread Tim Cross


torys.ander...@gmail.com (Tory S. Anderson) writes:

> I've been trying to debug a nearly show-stopping issue for a few weeks now; 
> the
> next step is a more thorough bisection of my setup, but I wanted to send this 
> in
> case anyone else experiences this or already knows the solution.
>
> Lately, when I try to view an orgmode agenda it seems that two things make it
> cause my emacs CPU threat to spin to max and freeze up, which is a huge 
> problem
> since I'm an exwm user and live in my agenda view. As far as I've been able to
> tell, when an item from today is clocked into multiple times in the same day, 
> it
> prompts most agenda actions to result in a freeze and some kind of loop that 
> is
> binding up my system. It has some gaps, so if I spam C-g I will eventually,
> usually, escape given 30 seconds to 2 minutes.
>
> I first ran into this problem thinking it was because I had an entry with a
> "+1d" note on it, so it would always show up; but inconsistent results led me 
> to
> the more precise discovery that it's apparently when it is logged in to 
> multiple
> times in the day AND when it is shown with =(org-agenda-show-log t)=, which I
> had on my default. At its worst, even moving the cursor in the agenda buffer
> would trigger the freezing, let alone actually clocking in/out of anything.
> However, when I am not showing the log, it seems like it's ok. I've tried
> =toggle-debug-on-quit" but I don't recognize anything in the stack trace that
> actually tells me what it is doing when it spins to a halt.
>
> I'm currently on org mode version 9.3.7. I've tried with different versions 
> but
> without a change in behavior. This, combined with the fact that the issues 
> seem
> to have begun in the past month, indicates that it probably isn't orgmode 
> itself
> causing this issue, but I haven't located what it IS yet. If anyone has ideas 
> on
> how to debug this without a bisection, or an has dealt with this before, I'm
> more than eager to hear it; in the meanwhile, I'll perform a more thorough
> bisection of my init file as time permits.
>

Does the problem also occur if your not running exwm? I stopped using
exwm for a very similar reason i.e. every now and then, I would try to
do something and the CPU load would peak, everything would become
unresponsive and either I had to wait (for minutes) or start killing
things to try and get back control. Probably first thing to do is see if
you can reproduce the issue without exwm. If you can, the next thing to
do would be to come up with a minimal org config and recipe to reproduce
as this will allow others here to try and help debug the issue. 

BTW I gave up on exwm as I found a few issues and found it often got
slow. I switched to Stumpwm (Common Lisp WM), which I found great as I
was then able to have a window manager which worked like Emacs, could
have same keyboard interface and could be modified 'on the fly' with
lisp. I only stopped using it when I started experimenting with Wayland.


-- 
Tim Cross



Re: async export and then do something with file

2021-04-29 Thread Tim Cross


Matt Price  writes:

> Hi everyone,
>
> I am wondering if I can perform and export asynchronously and then, without 
> tying up emacs, wait around for the export to finish and then perform
> some other task, like upload the file to a server.  Has anyone tried this 
> before? I think perhaps the easiest thing to do would be to use async.el or
> some similar third-party, but I can't tell what the preferred method is. I 
> would love osme guidance!
>

The asynchronous export should be possible and I've seen some proposed
patches for this discussed recently. The challenge is your second part. In 
other languages,
you could use something like a 'future' (Clojure) or a Promise
(Javascript), but I'm not 100% sure with Elisp. I suspect you would need
to create the async process and use the :sentinal option to pass in a
process sentinal function, which is essentially a function that will run
whenever the status of a process changes. The sentinal would need to
watch for a status change which indicates the process has finished and
then call whatever your post-export actions are.

HTH

Tim


-- 
Tim Cross



Re: [PATCH] ol.el: Fix confusing variable name

2021-04-29 Thread Tim Cross


"Aaron L. Zeng"  writes:

> * ol.el (org-link--open-help): Fix a confusing variable name.  No
> behavior changes.
>
> TINYCHANGE
> ---
>  lisp/ol.el | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/ol.el b/lisp/ol.el
> index 62ea6d2bc..617223cb5 100644
> --- a/lisp/ol.el
> +++ b/lisp/ol.el
> @@ -1325,8 +1325,8 @@ PATH is the sexp to evaluate, as a string."
>"Open a \"help\" type link.
>  PATH is a symbol name, as a string."
>(pcase (intern path)
> -((and (pred fboundp) variable) (describe-function variable))
> -((and (pred boundp) function) (describe-variable function))
> +((and (pred fboundp) function) (describe-function function))
> +((and (pred boundp) variable) (describe-variable variable))
>  (name (user-error "Unknown function or variable: %s" name
>  
>  (defun org-link--store-help ()

Hi Aaron,

thanks for the patch. It looks straight forward, does seem to be less
confusing and in-line with the intention of the code and is only a tiny
change, so I think it should be applied.

Tim

-- 
Tim Cross



Re: stability of toc links

2021-04-29 Thread Tim Cross


Samuel Wales  writes:

> hi trs,
>
> thank you.  i can imagine that could be useful for a lot of users, but
> for me, as i said in my op, "short of adding custom id
> or id to everything" --- i didn't want to add custom id.  i will try
> to clarify why in case it is useful.
>
> in addition to performance, and clutter, there is a semantic issue in
> my case.  typically, if i see that there is a properties drawer, i
> know that it is there because of an org id or a manual custom id or a
> special purpose of my own.  if i know it, i don't need to open it.
>
> however, adding custom id automatically for so many links means that
> there is a new meaning for properties drawers [namely, for stable
> linking done automatically].  i would have to open the drawer to
> determine if i personally wanted something there.
>
> and thus, the extra properties drawers would cause effort and
> distraction in this semantic sense, where i would be opening them
> because i would be thinking "did i really have a reason to add a
> properties drawer here? i don't recall so... better check"
>
> also, there is the issue that if i decide not to include something in
> the toc, it will still have a properties drawer lying around.
>
>
> in the op, i was not looking for a solution for one blog post, but
> thought a general solution for all org users might be possible.
>
> and this would likely be at the html level, probably by using e.g.
> header text, fuzzy or strict hashes, or a combination.
>
> when tec posted his html level code, it looked like the right type of
> solution to the problem.  i have not tried it, however.
>
> i hope that clarifies.  tec said he originally did not get much
> interest.  then there was interest on this thread.  then nothing.
>

A question to help me understand this issue.

If I understand correctly, exporting to HTML does not guarantee
stability of TOC links. If you export as HTML, send someone a link from
the toc and then re-export the document, the link will possibly be
broken. Essentially, exporting to HTML has no guarantee of stability in
toc links.

However, if you use publish instead of exporting to HTML, there is a
guarantee of stability in toc links. When publishing a second time, the
link will be consistent and still valid.

If you want stability in toc links, why not use publish instead of
export to html? Is there some difference between the two mechanisms
which prevents you from being able to use publish instead to get stable
links?



Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

2021-04-29 Thread Tim Cross


Timothy  writes:

> Colin Baxter  writes:
>
>> Debian 9.13 may be old but updates are still made available. While
>> Debian supports the os-version and therefore by implication emacs-24, I
>> feel org-mode shouldn't deliberately break that support.
>
> I have to admit, I'm not sure why Org support should stretch so far
> back. If it was a standalone thing, I could see it, but as it's
> vendored with Emacs I'm not sure why we don't just do stable Emacs - 1
> (i.e. 26.3 ATM).

I don't think we can set an absolute limit. It really depends on what
has changed in Emacs. For example, if Emacs adds some feature or
capability which really improves org performance, we might decide to
drop older versions sooner to try and get everyone onto a more
performant version. On the other hand, if new versions of Emacs don't
really add any significantly beneficial changes, we might continue to
support older versions for longer. We also need to consider changes in
the Emacs release cycle. In recent years, this seems to have been faster
than it use to be. Emacs 24.5 was released in April 2015, which is only
6 years ago. Emacs 25.3 was less than 4 years ago.

People do tend to upgrade their hardware every 3 - 5 years and it can
take distributions 2+ years to update the version they are shipping, so
in general, we probably do need to support major versions for up to 5 or
so years after release. However, this also needs to consider the adding
of lexical binding as a significant enhancement. The next 'big one' is
likely to be native compilation support for *.el files.

I do think it is probably time to drop support for Emacs 24 in the next
major release. However, we cannot drop it 'mid release'.


-- 
Tim Cross



Re: How to use `open` to handle `message:*` links on macOS

2021-04-29 Thread Tim Cross


Tim Visher  writes:

> Hi Diego and Alexander,
>
> Thanks for the tips here. I finally got around to trying them out. Here's 
> what I ended up with and it's working perfectly.
>
> (defun timvisher-org-link-mac-mail-open-link
> (mid _)
>   (start-process "open-link" nil "open" (format "message://%%3C%s%%3E"
> mid)))
>
> (defun timvisher-org-link-mac-mail-add-message-links
> ()
>   (org-link-set-parameters
>"message" :follow #'timvisher-org-link-mac-mail-open-link))
>
> (eval-after-load 'org
>   '(timvisher-org-link-mac-mail-add-message-links))
>
> Pairing that with my org-capture TODO Current Mail Template is a dream come 
> true. :)
>
> (defun timvisher-org-current-mail-get-selected-message-subject
> ()
>   (with-temp-buffer
> (call-process
>  "osascript" nil t nil
>  "-e" "tell application \"Mail\" to get subject of item 1 of (selection 
> as list)")
> (buffer-substring-no-properties (point-min) (- (point-max) 1
>
> (defun timvisher-org-current-mail-get-selected-message-id
> ()
>   (with-temp-buffer
> (call-process
>  "osascript" nil t nil
>  "-e" "tell application \"Mail\" to get message id of item 1 of 
> (selection as list)")
> (browse-url-url-encode-chars
>  (buffer-substring-no-properties (point-min) (- (point-max) 1))
>  "[/]")))
>
> (defun timvisher-org-current-mail-get-link-string
> ()
>   (let ((subject (timvisher-org-current-mail-get-selected-message-subject))
> (message-id (timvisher-org-current-mail-get-selected-message-id)))
> (org-link-make-string (format "message:%s" message-id)
>   subject)))
>
> (defun timvisher-org-current-mail-get-body-quote-template-element
> ()
>   (let ((body (setq body (with-temp-buffer
>  (call-process
>   "osascript" nil t nil
>   "-e" "tell application \"Mail\" to get content of item 1 of 
> (selection as list)")
>  (buffer-substring-no-properties (point-min) (- (point-max) 
> 1))
> (format "
>
>   #+begin_quote
> %s
>   #+end_quote"
> (string-join
>  (seq-reduce
>   (lambda (acc next)
> (if (string= next (or (car (last acc)) ""))
> acc
>   (append acc (list next
>   (mapcar (lambda (string)
> (let ((string (string-trim string)))
>   (if (string= "" string)
>   string
> (format "  %s" string
>   (split-string body "\n"))
>   '())
>  "\n"
>
> (setq org-capture-templates
>   '(…
> ("twcm" "TODO Work Current Mail" entry
>  (file+headline "~/Dropbox/todo/work.org" "Inbox")
>  "* TODO %(timvisher-org-current-mail-get-link-string)
>
>   %U%(timvisher-org-current-mail-get-body-quote-template-element)" :prepend t 
> :immediate-finish t)
> …))
>
> Thanks so much! :)

I think this would be great content to add to the worg site. Would you
be willing to add this, plus a short outline of the issue you needed to
resolve so that others might benefit from your experience?


-- 
Tim Cross



Re: [PATCH] Bug: fragile org refile cache

2021-04-29 Thread Tim Cross


Ihor Radchenko  writes:

> Samuel Wales  writes:
>
>> would it be more useful if it automaticaly generated the cache instead
>> of telling you to runt he command to do so?
>
> I think so. To be frank, I do not understand the reason why it is not
> done by default.
>
>> if a solid, perhaps unified, cache existed, would org-id use it too?
>
> Sure. Why not? I imagine such cache can store the following info:
>
> org files in system -> per-file cache -> per-heading cache -> ...
>

I suspect the reason it is not done automatically is that getting that
right for all use cases is very hard to do without adding adverse impact
to performance. A cache which is marked as 'dirty' too often results in
too frequent cache refresh operations, but at the same time, determining
what changes in an org file actually invalidate the cache can be a
process intensive operation. Allowing the user to force cache refresh
when needed is likely a reasonable compromise. 

I recall having a lot of trouble getting org-refile to work well for me.
I use it a lot, but it was so long ago, I don't recall how I got to my
final configuration (I think I may have modified my workflow to work
better with what I was able to get working reasonably reliably and
efficiently). I now tend to refile to a fairly static set of paths, so
all works OK.

Sorry I cannot provide anything more substantial. I do understand your
frustration, but not sure what the right fix is. I can see having a
cache which is automatically refreshed when necessary will be
problematic to get working for all use cases. Having the ability to turn
automatic refresh on/off and having the ability to manually force a
refresh will likely always be required.



-- 
Tim Cross



Re: [WDYT, mini] key h in agenda for quick help

2021-04-28 Thread Tim Cross


Bastien  writes:

> Timothy  writes:
>
>> Great to hear! I think this would probably be developed as a branch like
>> wip-cite-new
>
> Yes.
>
>> , and it would need transient to be installed (via ELPA?) on
>> Emacs <28, but I think it has the potential to both:
>>  - Improve the user experience, and
>>  - Remove Org's own home-cooked transient-ish interfaces,
>>so leave us with less code to watch over
>
> Yes, exactly.  Also there is plan to include Transient in Emacs core,
> so this makes this move even more appealing:
>
> https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00944.html

I would also suggest that if we were going to have a 'help' key, rather
than describe mode, it might be better to link to the info manual (you
could just link to the agenda section of the manual).

I've rarely found describe mode to be terribly useful (there are
exceptions). However, I have used modes which have bound a help key to a
section in the info manual and I've found that much more useful. The
depth of information is usually better (what people looking for help
probably want) and once your in the info pages, moving to cross
references and other possibly relevant sections is very easy.

I also think adding transient mode would be beneficial in a number of
areas of org. In addition to reducing code maintenance, it would
increase consistency with other Emacs modes etc.


-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-26 Thread Tim Cross


Bastien  writes:

> Hi Tim,
>
> thank you very much for your detailed answer.
>
> Tim Cross  writes:
>
>> Yes, but with some caveats. 
>
> Thank you!
>
>> For these reasons, I'm probably not the best person to assist with the
>> review and guidance for patches aimed at adding/extending functionality.
>
> The role of a "contributor steward" is to address the issues Timothy
> originally raised about contributors not receiving answers when they
> take the time to send a patch or a bug report, it is not about making
> technical decisions.  Of course, your advice as a long-time user on
> these decisions is always very welcome.
>
>> However, I would be happy to
>>
>> - Assist in trying to reproduce and confirm bugs
>> - Assist in extracting additional information and providing
>>   guidance/clarification for bug reports 
>> - Assist with documentation
>> - Provide some guidance on patches, particularly bug fixes.
>
> That's exactly what is badly needed to discharge core maintainers from
> routine tasks and to let them focus on technical stuff.
>
> This has basically been my role in my early years of maintainership:
> making sure to keep this list as welcoming as possible, to continue to
> attract new people with new ideas (and new bug report).  This is a
> somewhat undervalued role, but a deeply necessary one -- so again,
> thanks for helping here.
>
>> My time availability can vary greatly depending on work. 
>
> That's no problem.  We have a team of Tim's :)
>
>> Also, as a
>> blind user, my ability to reproduce bugs can sometimes be hampered by
>> the necessity of running Emacspeak in conjunction with org mode (they
>> can sometimes interfere with each other). However, apart from that, more
>> than happy to help where I can, so if your happy, sign me up!
>
> If the task becomes too much for you, you can always say that you
> won't be available for a while.
>
> Thanks!

OK, consider me 'singed up". Today I will see if I can re-jig my mail
system to make it easier to track and respond. As Timothy seems to be
doing a fine job 'catching up' with what is already on updates.orgmode,
I'll leave that alone and will focus on responding to new bug reports,
patches etc which come through the list.

I'll also setup a 'clean' virtual image so that I have a vanilla, clean
Emacs config I can use for evaluating/reproducing bugs (current emacs
stable 27.2). .

What is our position with bugs which can only be reproduced in the
current development version of Emacs? I'd expect we track them, but
focus more on Emacs stable given that dev is a moving target and any
bugs may be resolved by later changes in Emacs?

Finally, is it also necessary to monitor org bugs reported to the emacs
bug tracker or are they sent on to the emacs-orgmode list via some other
process? (I currently do monitor emacs-devel but not the bug tracker). 

-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-25 Thread Tim Cross


Bastien  writes:

> Hi Tim,
>
> Tim Cross  writes:
>
>> I agree and am willing to help if I can.
>
> Great!  Would you agree to be "officially" appointed to this role,
> with Timothy?  I put quotes on "officially": when moving toward the
> new maintainance team, I'd like to list maintainers and their roles,
> including the "contributor stewards".  If you prefer not to publicly
> appear but still work on this, that's perfectly okay too, of course.
>

Yes, but with some caveats. As may have already been picked up by some,
I'm extremely conservative regarding the addition of new features and
enhancements to org mode. I have considerable concern regarding both the
performance and maintainability of the mode and worry about the
increasing complexity in options, performance impact from increasingly
complex font locking just to have more 'eye candy' at the cost of
sluggish behaviour for large files and striking the right balance
between the 'richness' of org file functionality and consistency in
exporters or source block handling. I really would hate to see org mode
end up like MS word with 90% of users only using 10% of the
functionality with 90% unused functionality just becoming a burden to
maintainers.

For these reasons, I'm probably not the best person to assist with the
review and guidance for patches aimed at adding/extending functionality.
However, I would be happy to

- Assist in trying to reproduce and confirm bugs
- Assist in extracting additional information and providing
  guidance/clarification for bug reports 
- Assist with documentation
- Provide some guidance on patches, particularly bug fixes.

My time availability can vary greatly depending on work. Also, as a
blind user, my ability to reproduce bugs can sometimes be hampered by
the necessity of running Emacspeak in conjunction with org mode (they
can sometimes interfere with each other). However, apart from that, more
than happy to help where I can, so if your happy, sign me up!

>> One thing I do think would be helpful, particularly for documentation on
>> maintenance of org mode, would be a clear outline of project goals and
>> philosophy. Some of this would be 'concrete' statements, such as the
>> minimum supported Emacs version, size of contribution and requirements
>> to sign FSF copyright assignment paperwork, inclusion of acceptance
>> tests, documentation, maintenance of backwards compatibility, API
>> stability etc. Other parts would be more 'fuzzy' guidelines, such as
>> avoiding complexity and 'blow out' in options/arguments, balancing
>> features and maintainability, what should become part of org core and
>> what should be in contributions or a completely separate add on package
>> and what guidelines are used in assessing extensions/enhancements for
>> inclusion etc.
>>
>> It will be challenging to define this as there are a wide diversity of
>> views and priorities amongst the community. However, I think it would be
>> an overall benefit for both the community and on-going development of
>> org mode. 
>>
>> While I would be happy to help with this, I think the initial content at
>> least needs to come from current key maintainers and if possible, some
>> input from Carsten would be good. 
>
> Fully agreed.  Input from old timers will be precious, too.  I will
> work on this as we are transitioning to the new maintainance team.
>
> Also, I commit to achieve this transition by August, 1st.  This may
> seem a bit far away, but there is really no rush here, and I want to
> ensure we have a smooth transition.

All your efforts greatly appreciated. It is a lot of effort and herding
cats often takes a lot longer then anticipated! 

-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-25 Thread Tim Cross


Bastien  writes:

> Dear Timothy,
>
> thanks for raising this points so carefully, they are important.
>
> I see three distinct problems:
>
> 1. The lack of response and/or follow-up when people contribute by
>sending bug reports or patches on the list.
>
> 2. The lack of maintainance on documenting the contribution process
>and the correct expectations for future contributors.
>
> 3. The inherent difficulty to move the Org codebase forward.
>
> I won't comment on (3).  For (1) and (2), I suggest appointing a
> "contributor steward" with these responsibilities:
>
> 1. Maintain updates.orgmode.org (i.e. make sure it is accurate.)
> 2. Maintain the documentation for contributors.
> 3. Help contributors enhancing their patches.
> 4. Try to reproduce bugs (and confirm them for updates.orgmode.org)
> 5. Make sure patch contributors are not left with no answer.
>
> You started (1), which is really appreciated.
>
> Tim and others mentioned (2), and that's certainly needed too.
>
> (3) has historically been the role of the maintainer and of the core
> contributors, but helping with this is very welcome: knowing the doc
> at https://orgmode.org/worg/org-contribute.html by heart, educating
> contributors on the commit messages, etc.  This all helps.
>
> (4) is perhaps the most daunting task: I even think we could have
> someone only dedicated to this very important task.  Just count the
> number of times Nicolas says "I cannot reproduce this."  Each time,
> there is a real bug that is *not* fixed...
>
> (5) is not about systematically welcome patch submitters with a
> message (that would be annoying) but to monitor updates.orgmode.org
> and decide what to do with a patch that didn't receive feedback:
> either say thanks and ping the list for why you think the patch
> deserves more attention, or thanks and dismiss the patch, or another
> answer.
>
> What do you think?  Would you be willing to take this role?
>
> If not, that's perfectly okay, I'll send a call for help.
>
Hi Bastien et. al.

I agree and am willing to help if I can.

One thing I do think would be helpful, particularly for documentation on
maintenance of org mode, would be a clear outline of project goals and
philosophy. Some of this would be 'concrete' statements, such as the
minimum supported Emacs version, size of contribution and requirements
to sign FSF copyright assignment paperwork, inclusion of acceptance
tests, documentation, maintenance of backwards compatibility, API
stability etc. Other parts would be more 'fuzzy' guidelines, such as
avoiding complexity and 'blow out' in options/arguments, balancing
features and maintainability, what should become part of org core and
what should be in contributions or a completely separate add on package
and what guidelines are used in assessing extensions/enhancements for
inclusion etc.

It will be challenging to define this as there are a wide diversity of
views and priorities amongst the community. However, I think it would be
an overall benefit for both the community and on-going development of
org mode. 

While I would be happy to help with this, I think the initial content at
least needs to come from current key maintainers and if possible, some
input from Carsten would be good. 

-- 
Tim Cross



Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

2021-04-22 Thread Tim Cross


Anthony Carrico  writes:

> On 4/20/21 12:55 AM, Tim Cross wrote:
>> The error from libreJS is correct - public domain is not a valid
>> license.
>
> Everyone is licensed to use public domain works (except to obtain a copyright 
> on
> them). I think you mean that libreJS is working by design when it blocks them,
> which is apparently the case.

What I meant is that Public Domain is not a license - it means the
content cannot be copyrighted, which effectively means it is compatible
with a free license, but the content lacks a formal license. The CCO
also puts the content into the public domain, but also includes a formal
license as a fallback, which can be beneficial in some jurisdictions.   

>
>> As this is a GNU project and correct licensing is important...
>
> Emacs is a GNU project, but org-mode export is a document processor, and the
> goal here was to avoid including licensed content in an Author's exported
> documents.

Appreciate the intention. Perhaps we need to clarify what exactly we are
licensing here - the content or the Javascript added to the content to
facilitate presentation. The content should be covered by whatever
license the author prefers. The Javascript on the other hand, if
generated by Org, should probably be covered by the GPL as it is
'created' by org. If the document author has not written the Javascript,
I'm not sure they have the right to set the license on it, especially if
it was generated as part of software covered by the GPL.

The CC0 is appropriate for content which is in the public domain. It
is essentially equivalent to public domain, but with a fallback trivial
free license, which can be a useful addition in some jurisdictions.
However, it is less suitable for software (i.e. Javascript) because it
lacks any protection from patent trolling.

-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-21 Thread Tim Cross


ian martins  writes:

> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross  wrote:
>
>  Responding to essentially just flag you have seen the patch message
>  really only adds noise and may even 'drown out' those responses which
>  add real 'value' to any discussion. I also doubt that asking people to
>  do this would actually result in any actual change of behaviour by
>  subscribers.
>
> Timothy said there were 25 patches without response and the list goes back 
> six months, so we're only talking about 50 emails per year.

That assumes there is a single 'owner' who accepts the responsibility to
respond to every patch submitted. That isn't the situation with open
source projects where people volunteer their time.

Having someone respond to the author of a patch and provide some
meaningful feedback would be great, but I don't see how that can happen
in a project which is already stretched and with limited resources.
There has already been multiple messages requesting additional help and
for volunteers willing to put in the time needed to maintain parts of
org mode. Adding to that workload isn't going to help. 

responses to patches really need to come from community members who are
sufficiently interested in the patch to examine it or make comment on
how useful they feel it would be. To some extent, if someone submits a
patch and hears nothing, either they have failed to clearly explain what
the patch does (and therefore did not tweak any interest) or it is a
patch to introduce functionality which is of low interest to community
participants.

I think you can classify patches into 3 basic types -

1. Bug fixes. Patches which do not change functionality, but address
bugs and performance bottlenecks in existing features. At present, this
type of patch seems to get applied fairly quickly.

2. Patches which extend existing functionality. This type of patch
requires significant consideration and evaluation. They can be time
consuming to assess and a call needs to be made as to whether the
additional complexity such enhancements add can justify the increased
maintenance overhead such enhancements introduce. This is particularly
challenging with org mode because org supports a diverse and sometimes
complex range of workflows. Verifying an enhancement will not have
adverse impact on some of these workflows is difficult and time
consuming. Even apparently simple and straight-forward changes can have
unexpected impact - consider for example the enhancement to support
electric indent mode. This seemed fairly straight-forward and was a
change which made org mode aligned with other Emacs modes and helps
improve consistency withing Emacs across modes. However, it has had some
adverse impact and caused some confusion because of how it interacts
with existing org behaviour and configuration settings, such as with org
indentation behaviour.

3. Patches which introduce new functionality. This type of patch also
requires considerable resources to evaluate and adds to overall
maintenance load. It is one thing to write an extension, but a
completely different thing to maintain it over time. Even assessing the
real demand for such extensions is challenging and time consuming and
represents a significant demand on volunteers time.

Asking volunteers to respond to patches of type 2 and 3 within some
nominated time period is probably unreasonable. It also runs the danger
of discouraging people from stepping up to volunteer to help maintain
parts of org. This is why I think a better approach would be to provide
more details and explanation on patch submission which can help set the
expectations for the patch submitter and provide some guidance on what
to do if they want to encourage/ask for feedback.

This is also part of why I think patches of type 3 and possibly many
type 2 patches should be initially released as separate 'add on'
packages and made available via gitlab/github/melpa by the individual
responsible for writing the patch. The author would then be able to see
how useful/popular/desired their patch is, be able to ask for feedback
and be able to get issue/bug reports to refine their work. This could be
viewed as an 'incubator' like process. If such an enhancement/extension
turns out to be very popular or demanded by the org community, it could
then be migrated into either org core or the proposed org contrib
package (by which time, it would likely be more mature and stable than
it was when initially developed). It also has the advantage of not
impacting existing org users who are not interested in the
enhancement/extension. For an org user, little is more frustrating than
an enhancement/extension which results in them having to either modify
their workflow or update their often large repository of org documents. 

If we were to provide a detailed explanation on how to contribute bug
fixes, enhancements and extensions on the worg site, contributors will
know what is required, will be able to s

Re: Using backticks for the inline code delimeter?

2021-04-21 Thread Tim Cross


John Kitchin  writes:

>> The challenge can be in identifying the most appropriate key bindings.
>> This can depend on the platform you use as well. When I was only using
>> Linux, I used the 'super' key for this and it was great. However, when I
>> also started using a mac, I had to define a new scheme. It can take a
>> bit of work to setup initially, but I think it is worth the effort. I
>> now have the same bindings in multiple modes, so regardless of whether
>> I'm writing markdown, org, html, rich text, etc, I just hit the same key
>> bindings to mark content as code, bold, italic, etc.
>
> On a Mac, you might find these useful. I don't use the right command and
> option keys, so I redefine them as hyper and super. they are right under
> my thumb, and convenient.
>
> (setq mac-right-command-modifier 'hyper)
> (setq mac-right-option-modifier 'super)


That is useful information. The 'hyper key is certainly overlooked and
provides a very useful mechanism to create a whole set of new, possibly
short, key bindings. I like the idea of re-tasking the right hand
command/option keys as it is very rare I use them (command/option is
most used via left hand side for me).

-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-21 Thread Tim Cross


"Bruce D'Arcus"  writes:

> I've been thinking about this general issue over the past year, as
> it's a common problem regardless of project, hosting platform, etc.
>
> I do agree in general that situations where submission of ideas and
> patches languish without attention are a problem.
>
> But while I don't think there are any easy answers, I do think clarity
> upfront can help.
>
> For example, perhaps there needs to be a prominent statement early on
> this page, which states upfront how the community vets new ideas or
> patches, what someone who submits such can expect, including in terms
> of timeline, and how to interpret lack of response?
>
> https://orgmode.org/worg/org-contribute.html
>

Yes, we can certainly help manage expectations, which I think is going
to be more effective. At the very least, it is a good place to start.
Perhaps it would be worthwhile if everyone interested in this issue have
a look at what is on worg about contributing and propose some additions/updates?

Responding to essentially just flag you have seen the patch message
really only adds noise and may even 'drown out' those responses which
add real 'value' to any discussion. I also doubt that asking people to
do this would actually result in any actual change of behaviour by
subscribers.

-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-21 Thread Tim Cross


Eric S Fraga  writes:

> On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote:
>> 1. A patch looks useful to me, but I feel I don't know if it's a good
>
> [...]
>
>>"Thanks for submitting this. I'd use it.  Hopefully a maintainer
>>will take a look."
>
> Ian,
>
> I think you will find that a few of us do post answers like this every
> now and again.  I know that I do.
>
> The lack of answers to cases 2 & 3 are essentially showing a lack of
> interest which is basically an (implicit) answer as well.  It may seem
> dismissive but, given the volume of email some of us have to deal with
> in our day job, it's just reality, I would suggest, without it meaning
> to be judgemental in any way.
>
> (now back to my day job ;-))

+1. If a patch is of interest to me, I usually respond. I don't respond
to patches which are of no interest or which I don't understand.

-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-21 Thread Tim Cross


Jean Louis  writes:

> It should be clear that more maintainers and developers with direct
> access are needed for patches to be applied timely.
>
> I am sure that those on emacs-devel mailing list, Emacs developers,
> they could help on that, but maybe some of them do not observe this
> mailing list.
>
> Number of not applied patches does not seem to be that large.
>
> Project leader shall have his team and delegate them to other
> developers.
>
> This situation badly contradicts to Org mode purposes which is meant
> to manage patches.
>
> Maybe there shall be a published list of developers and project
> managers, so that this type of communication may be addressd
> properly. As now original poster explained the problem, but I did not
> see response from none of pushers, I mean those who have repository
> access.
>
> So how many people are there who have repository access?
>
> Who is not busy but willing to apply at least 1-5 patches pending?
>

I'm not sure I agree with this analysis. As Timothy mentioned a few
times, the issue is NOT about the time taken to apply patches. It is
about a lack of feedback regarding the state of the patches.

Increasing the number of people with the ability to apply
patches/changes to the repository is unlikely to be helpful. It could in
fact have the reverse result, leading to increased inconsistency and
reduced stability.

I find bug fixes are applied very quickly. Enhancements and extensions
are introduced more conservatively, but I think that is a positive
rather than negative aspect of org development. For many users, org is
already very feature rich/complete.


-- 
Tim Cross



Re: Using backticks for the inline code delimeter?

2021-04-20 Thread Tim Cross


Matt Price  writes:

> On Wed., Mar. 31, 2021, 3:22 p.m. Timothy,  wrote:
>
>  autofrettage  writes:
>
>  > Quick and Dirty: Bind key '`' to ~ in Emacs?
>  >
>  > (I guess it is clear I haven't thought about the consequences.)
>
>  You can add that just to the Org-mode map. That wouldn't be too bad,
>  there's always C-q.
>
> Is it possible to bind a key in org-mode but bind it back to another 
> character if you're in a special environment, eg a code block? That would
> probably be my preference. So "`" inserts "~" when you're writing text but 
> "`" in an elisp or markdown SRC block, for instance. 
>
> I guess just write a function that checks context? Presumably all the 
> overloaded keybindings do this already but I guess I don't really know how 
> they
> do so. 
>

Yes, you can do that. However, results can vary. The 'bottleneck' is in
determining context. If that is easy, typically no problems. However, if
you need something complex or need to scan a large part of the buffer to
determine the context, then it can be problematic. 

> I do in general wish it were easier to switch between writing markdown and 
> writing org, since I often have to write markdown for work. 
>

Sounds like what you really need to do is define a set of key bindings
which use the same bindings in both org and markup modes (different
bound functions obviously). Instead of entering the character for 'code'
using org syntax when in org and markdown syntax when in markdown,
you just train your fingers to hit the key binding you have defined for
entering 'code'. One nice advantage of this approach is that you can
define functions such that if you hit that key binding it will insert
the mode specific character if no region is selected, but if a region is
selected, wrap that region using the nominated character. This is handy when
editing a document because if you come across a section and want to have
it rendered has code, bold, underlined etc, you can just select the
target region and hit the appropriate key and job done.

The other nice thing about this approach is you can generalise this
further to other modes, even HTML. You then think in terms of either
formatting or semantics (depending on how you define the bindings) and
not the lower level syntax. 

The challenge can be in identifying the most appropriate key bindings.
This can depend on the platform you use as well. When I was only using
Linux, I used the 'super' key for this and it was great. However, when I
also started using a mac, I had to define a new scheme. It can take a
bit of work to setup initially, but I think it is worth the effort. I
now have the same bindings in multiple modes, so regardless of whether
I'm writing markdown, org, html, rich text, etc, I just hit the same key
bindings to mark content as code, bold, italic, etc. 

-- 
Tim Cross



Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

2021-04-19 Thread Tim Cross


Kyle Meyer  writes:

> Jorge P. de Morais Neto writes:
>
>> Hi.  The HTML export has JavaScript that LibreJS does not recognize as
>> free.
>
> Thanks for noting this.  That's certainly not ideal.
>
>> My first attempt at an workaround (inspired by the Org Mode mailing
>> list) was merely encoding the ampersand in the magnet link, but that
>> *did not make LibreJS happy*.  Then I checked LibreJS manual and saw
>> this excerpt:
>>
>> https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1
>>
>> Public domain is not a license (see
>> https://www.gnu.org/licenses/license-list.html#PublicDomain).  If
>> you want to release your work to the public domain, the FSF
>> recommends using CC0.
>>
>> Then I came up with a successful workaround.  I included the following
>> code in my Org Mode customization file:
>
> Hmm, the public domain switched happen with 471054136 (ox-html.el: Use
> classList and put in the public domain, 2020-09-05) and the associated
> thread is
>
>   https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/
>
> (+cc author and committer)
>
>> ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS
>> (with-eval-after-load 'ox-html
>>   (setq org-html-scripts
>>  (string-replace "\
>> // @license 
>> magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a=public-domain.txt
>>  Public Domain"
>>  "\
>> // @license 
>> magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08dn=cc0.txt 
>> CC0-1.0"
>>  org-html-scripts)))
>>
>> This works; it makes LibreJS happy.
>
> Okay.  Anthony/Bastien/others, thoughts on using CC0 instead?

The error from libreJS is correct - public domain is not a valid
license.

As this is a GNU project and correct licensing is important, I don't
think there is any option other than to change the line to reference the
CC license (or any appropriate free license). If 'public domain' was
used due to some other issue, either we have to verify the code is
covered by a free (not just open source) license or replace it with code
that is and is acceptable by the FSF. 
-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-19 Thread Tim Cross


David Masterson  writes:

> Tim Cross  writes:
>
>> I suspect the best model for moving forward is for new features and
>> enhancements to be initially implemented as add on contribution packages
>> rather than as extensions/enhancement to the core 'org-mode' package.
>> Such packages, if found to be popular or useful to a large number of
>> org-mode users could then be considered for inclusion as part of the
>> main org-mode package. The nature of elisp makes this type of model very
>> suitable as you can modify almost any aspect of org-mode via add on
>> packages in a consistent and stable manner and avoid impacting the core
>> functionality until the extension/enhancement has matured
>> sufficiently.
>
> What is the current status of having a BNF (or...?) parser for Org
> files?  In particular, the parser rules that could then be adopted by
> tools that use Org files on other systems (iPhone, Android, ...)?  Given
> the availability of parser generators (bison...), this would be good for
> breaking into smartphones where Emacs doesn't run.

While not BNF, Tom Gillespie has been working on documentation of the
org grammar as part of a broader objective to make it easier for other
external tools to parse org files. Below is a message he recently posted
to the list.

Note that I think this is a slightly different topic to the
development/maintenance of org-mode. The external packages I was
referring to are still Elisp based packages. Non-Elisp tools which can
parse and possibly edit org files would be a good thing for accessing
org files on other devices and outside of Emacs. However, such tools
will always be more limited because of the complexity of adding things
like multiple export formats, babel tangling of src blocks etc (most of
which was really only viable in Emacs because Emacs already had support
for much of that functionality - a subtle point of org mode often
overlooked is that what it primarily did was take existing Emacs
functionality and 'wrapped' it in a UI layer to provide a more
consistent and 'directed' interface to existing Emacs functionality).

 > From Tom Gillespie 

 > Dear all,
 >Here is a draft of a formal grammar for Org mode [1]. It is still
 > in a rough state, despite quite a bit of work. However, following some
 > changes to improve performance for parsing real (big) Org files, I
 > think it is time to share it with the community so that we can start
 > to gather feedback. There are a number of opportunities that I have
 > found for simplifying the org grammar (sometimes by extending it to
 > make it more regular, and in the process adding useful features) that
 > are much easier to understand with this grammar in hand as a
 > reference. The grammar itself is implemented using Racket's #lang brag
 > (see [2] for an overview of brag's syntax). I had considered trying to
 > break it up into literate sections in an Org file, but for now decided
 > to leave it as a single file to simplify the development workflow. As
 > a result the full implementation is fairly long [3]. Comments and
 > feedback would be greatly appreciated. Best!
 > Tom
 
 > 1. https://github.com/tgbugs/laundry
 > 2. https://docs.racket-lang.org/brag/#%28part._.The_language%29
 > 3. https://github.com/tgbugs/laundry/blob/master/org-mode/parser.rkt
 
-- 
Tim Cross



Re: Concerns about community contributor support

2021-04-18 Thread Tim Cross


Timothy  writes:

> Tim Cross  writes:
>> This is a common development path for a successful project. Kent Beck
>> (extreme/agile development) has been focusing a bit on this with his 3x
>> development model (eXplore, eXpand, eXtract). (see
>> https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539).
>> To some extent, we are in an expand/extract stage for org mode. Focus is
>> on addressing performance and extracting core functionality - new
>> 'features' need to demonstrate a high level of 'return on investment'.
>> At this stage, enhancing or extending the functionality is a slower and
>> more cautious process which requires greater justification than was
>> common in the 'explore' stage.
>
> Interesting link, thanks. Org being in the expand/extract stage
> certainly rings true to me from my exposure.
>
> That said, I don't see why being in this stage of development means we
> don't need to acknowledge people's attempted contributions.
>

This is probably just a reflection of how a largely community driven
approach works. There isn't really anyone with a responsibility to
respond or reply to a patch within some acceptable 'time'. There is a
very limited number of people who have commit rights and who do apply
patches etc. At this time, priority appears to be given to patches which
fix existing behaviour (bug fixes) over ones which extend or modify
existing behaviour (enhancements and new features). 

I suspect the level of response something receives is a reflection of
the level of relevance or interest to others on the list. Personally, I
don't respond to messages which either

- Don't have relevance to how I use org mode. 

- I don't understand the objective or reason/rationale. 

- I don't agree or believe the idea is a good one. Sometimes I will reply
  if I feel (very subjective) the idea would have negative consequences
  in general or I think there is a simpler alternative solution.
  However, often I will take a wait and see approach before contributing
  anything. 

> My concern is centred around the lack of /response/ to people sending
> in patches. Radio silence for *six months* after sending in a
> contribution seems ridiculous to me.
>

I don't think it is ridiculous. I think it is more a reflection of how
less formal and structured approaches work. I can understand why someone
who has put in the effort to create and submit a patch would appreciate
some feedback, but I'm not sure an expectation or desire for feedback is
sufficient.

Personally, I feel that if you make a patch submission, you sometimes
need to 'sell' the patch. This is especially true if the patch is not a
basic bug fix. Having developed a patch, it is easy to become very close
to it and assume aspects of the patch or what it is proposing are self
evident. It can be challenging to put yourself in the shoes of someone
encountering the patch for the first time and consider how your
submission will come across. Simply submitting the patch and expecting
feedback may not be sufficient and followup posts will be required to
either clarify, remind or encourage feedback. 

> This is an interesting thought. Putting aside the fact that this is
> somewhat tangential to points I wished to discuss, I have a number of
> reservations:
> + Many patches are modifying core functionality, and would not be
>   suitable as an add-on (e.g. [1], [2], [3], and more)

There is no limit on what additional external 'add on' packages can do.
They can easily modify core functionality. This is one of the core
benefits/strengths of lisp languages. I can redefine a core function in
my add on package and provided my package is loaded after the core, my
redefined version of the function will be what is executed when the core
uses that function. For example, I have a heavily 'patched' version of
org mode, but I never actually change the core org code. Instead, I have
my own org configuration which redefines and modifies core functionality
which I wanted changed to suit my requirements.

I'm not totally clear about what sort of acknowledgement you want/expect
for patch submissions. I get the impression it is more than a simple
"thank you for your patch" and rather more detailed review/feedback of
your patch. For the latter case, it is likely more a reflection of
available resources - in particular, people with the necessary elisp
skill to be able to review and provide valid feedback and available time
for those limited resources. My observation, which is just one view, is
that bug fixes get priority and other patches get attention based on a
combination of community interest, available time and the 'squeaky
wheel' principal. This relates to my point about needing to 'sell' your
patch. For example, I had a quick look at some of the patches you
referenced. None of them had any relevance to my use of 

Re: Concerns about community contributor support

2021-04-17 Thread Tim Cross


"Thomas S. Dye"  writes:

> Aloha Timothy,
>
> working on Org mode (my interpretation), Nicolas Goaziou took over most of the
> coding work.  His brief was clearly to put the Org mode code into better 
> order,
> which he did with astonishing efficiency and expertise (at least from my often
> ignorant and confused perspective).  His work on the syntax, exporter, linter,
> and manual represents IMHO an outstanding contribution to Org mode.  I'm sure
> there are other important contributions that I'm not remembering right now.  
> My
> point is that the project changed from one that was expanding its own vision 
> of
> what it might be to one that was working to ensure that it wouldn't collapse
> from its own weight.
>

Totally agree. The work Nicolas has put in to consolidate, stabilise and
clarify the org code base has been critical to the long term viability
of the project.  I very much appreciate the work he has contributed and
the many times he has assisted me in understanding how things work
within org-mode.

> Kyle Meyer is the next step in this direction, whose efforts have helped tame
> the discussions on the Org mode list with a remarkable facility for threading
> together the various strands of discussion, some of which have histories that
> comprise several years. Combined with a command of git, his work has brought 
> the
> discussion into closer contact with the development of the code base.
>

Also agree. Getting the right balance between features, stability and
maintenance is extremely challenging. This is especially so with
org-mode as it has a level of flexibility which makes for a very wide
set of use cases. Identifying what should be part of 'core' and what
would be better off as an extension or add-on is often challenging. What
may seem like a great addition/enhancement for one may be of no benefit
to another or may actually complicate their use case. It can be
challenging to understand and interpret all these different perspectives
and determining the optimal forward direction. 


> These changes mean that contributions need to be checked for contributions to
> Nicolas' project and also fit into the history of discussion and development.
> The Org mode project now resembles a scholarly discipline that moves slowly 
> and
> deliberately toward a more or less well defined goal.  The days when Carsten
> would bang out a new feature during his train ride home from work are gone.

This is a common development path for a successful project. Kent Beck
(extreme/agile development) has been focusing a bit on this with his 3x
development model (eXplore, eXpand, eXtract). (see
https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539).
To some extent, we are in an expand/extract stage for org mode. Focus is
on addressing performance and extracting core functionality - new
'features' need to demonstrate a high level of 'return on investment'.
At this stage, enhancing or extending the functionality is a slower and
more cautious process which requires greater justification than was
common in the 'explore' stage.  

>
> Bastien did recently call for maintainers, though IIRC he was interested in 
> ox-*
> and ob-* maintainers more than org-* maintainers.  If enough good programmers
> heed his call, then there might be some progress on the concerns you raise.
> But, my sense is that patches to Org mode proper will continue to be adopted
> slowly and deliberately.  It would be a shame if that pace put off talented
> programmers, but my sense FWIW is that the pace might be necessary until the
> code base is fully tamed.
>

>From my perspective, I see bug fixes applied fairly quickly.
Enhancements and extensions are applied more conservatively, which I
think is the correct approach. 

I suspect the best model for moving forward is for new features and
enhancements to be initially implemented as add on contribution packages
rather than as extensions/enhancement to the core 'org-mode' package.
Such packages, if found to be popular or useful to a large number of
org-mode users could then be considered for inclusion as part of the
main org-mode package. The nature of elisp makes this type of model very
suitable as you can modify almost any aspect of org-mode via add on
packages in a consistent and stable manner and avoid impacting the core
functionality until the extension/enhancement has matured sufficiently.


-- 
Tim Cross



Re: On the protection of emails in the archives

2021-04-09 Thread Tim Cross


Jean Louis  writes:

> Sorry Tim. While that is my opinion, it is not meant to be taken
> personally, I am corresponding with many people with Google account,
> that is really nothing personal.
>

Your statement was personal and if that was not your intent, then think
before you post and ensure what you write is what you mean. 

> My opinion is for safety of users and awareness, though. Would you
> stubmle upon similar opinions on websites, it would not be taken that
> way. I did not mean to.
>

Completely irrelevant. I did not join the org list to be lectured by you
on privacy or your Google paranoia. I'm sure you can find a more
appropriate outlet for such opinions. 


> Examples of privacy nightmare:
> https://medium.com/digitalprivacywise/why-you-should-stop-using-google-chrome-6c934c9a827c
>
> Example of surveillannce:
> https://en.wikipedia.org/wiki/PRISM_(surveillance_program)

I'm not at all interested in your opinion on Google. This is an org mail
list. If it does not relate to org or the list, I don't think it belongs
here. 

-- 
Tim Cross



Re: On the protection of emails in the archives

2021-04-09 Thread Tim Cross


Jean Louis  writes:

> Nobody should use Google for emails. Why trust some 100,000 staff
> members with personal information?

Please do not tell me what I should or shold not do. I am an adult 
and am perfectly capable of making up my own mind thank you. 
-- 
Tim Cross



Re: On the protection of emails in the archives

2021-04-09 Thread Tim Cross


Kyle Meyer  writes:

> Guillaume MULLER writes:
>
>> Hi all,
>>
>> I recently sent an email on this mailing list (see
>> https://orgmode.org/list/b1e778c5-acbf-8a17-c9bf-dcb6693e9...@univ-st-etienne.fr/
>> )
>>
>> Since then, I'm receiving spams on the email address I used to send
>> the message.
>>
>> After some research, it seems that this email address only appears on
>> 2 websites, notably this orgmode.org mailing list archive.
>
> Your email address can also be harvested from the lists.gnu.org
> archives.  Inspect the output of
>
>   $ curl -fSsL 
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-07/msg00125.html
>   $ curl -fSsL https://lists.gnu.org/archive/mbox/emacs-orgmode/2020-07
>
>> Would it be possible to configure the archive to obfuscate / hide the
>> email addresses inorder to protect its users?
>
> <https://orgmode.org/list> and its upstream source
> <https://yhetil.org/orgmode> are public-inbox
> (<https://public-inbox.org/>) archives.  There's an option (disabled by
> default) to configure address obfuscation.  However, in my view email
> obfuscation is giving you a false sense of security.  Ignoring other
> ways spammers get your address, you're posting to a public space, and
> your address can be harvested (and, as shown above, not just from these
> public-inbox archives).
>
> And this isn't something specific to Org mode's archives.  Just as some
> examples, take a look at <https://lore.kernel.org/git/>,
> <https://issues.guix.gnu.org/>,
> <https://lists.sr.ht/~sircmpwn/sr.ht-discuss/>, or
> <https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00285.html>.
>
> Anyway, that being said and despite my opinion on this, I'm considering
> turning on obfuscation at <https://orgmode.org/list> and
> <https://yhetil.org/orgmode>.  There's at least one issue that'd need to
> be fixed before doing so though:
> <https://public-inbox.org/meta/87a6q8p5qa@kyleam.com/>.

I totally agree. I have no issue if 'hiding' email addresses can be done
and has no other unfortunate side effects, but I don't believe it
actually achieves much, so don't care if the default is not changed.

I think you have to accept that the email address you use in public mail
lists is going to be harvested and as others have mentioned, a lot of
email harvesting occurs when someone who has your address in their
address book has their system compromised.

The only sane action is good spam filtering. While I know a lot of
people complain about the Google gmail spam filtering, for me it is
remarkably accurate. It is unusual for me to see even a couple of spam
messages in my inbox every few months. My spam/junk box usually gets
around 10-15 messages a day and occasional messages flagged as spam
which are not (usually because the sender's mail server isn't doing SPF
or any of the other spam prevention headers correctly). Takes me about 1
minute to scan and 'delete forever' each day, so no big problem.  
-- 
Tim Cross



Re: First steps exporting to tex

2021-04-04 Thread Tim Cross


> Hi Tim

> I have been exporting from orgmode to PDF time ago, but very basic PDFs, 
> playing with some basic options of orgmode. When I tried to produce a
> meeting minute with a logo in the heading, I decided that I should learn 
> better a way of exporting, because the minute meeting was a first
> challenge, but many more would come. For example, for that task I started 
> with this code, which I think it goes far beyond what the "LaTeX
> Defaults" can offer (I must yet "play around" a lot with it):

> #+BEGIN_SRC

> #+options: toc:nil
> #+options: num:1
> #+options: d:nil
> #+export_file_name: BORRAR
> #+options: broken-links:mark

> #+LaTeX_header_extra: \usepackage{fancyhdr}

> #+begin_export LaTeX
> \thispagestyle{fancy}
> \lhead{\includegraphics[width=4cm]{//192.168.1.2/f/LOGO-IMAGEN 
> CORPORATIVA/IMAGEN CORPORATIVA 2018/DEFINITIVO
> ANAGRAMAS/SELLO1_grueso.png}}
> \rhead{Student Name: John Doe\\
> Student ID: 1234\\
> Course: IDB 601 (Fall 2020)}
> #+end_export
> #+END_SRC

> The buffer I exported my meeting notes from has much more information which 
> is not related with meetings nor with the logo. So I foresaw 3 things:

> 1 A fast cluttering of the buffers with LaTeX headings would happen, as I 
> will learn more about LaTeX and I will want to add more and more
>  packages. 
> 2 A need for flexibility to be able to export different kinds of documents 
> from the same buffer, ideally achieved just by changing a line (or few lines)
>  in the buffer. Although, from my example, it seems that ~#+begin_export...~ 
> contents can't be added in that way.
> 3 A great potential if it were possible to use already existing, and well 
> curated, LaTeX templates frictionless through orgmode.

> I find quite useful to analyse the default generated TeX file though.

> Best regards

OK, now I understand your objectives a bit more there are a couple of
things I would recommend.

Org is already fully setup to provide a clean and consistent way to do
much of what you are currently achieving with export latex blocks and
which can avoid much of the clutter in your org files. The way you are
customizing the latex etc is OK for 'one off' type hacks, but isn't the
best solution for crating a standard format. 

Have a look at the documentation for org-latex-classes. In this
variable, you can define your own 'pseudo' classes, which you can then
use in your org file with a simple #+LATEX_CLASS: line. This will take
care of all the preamble stuff, plus more (it uses other org variables,
such as ones for listing default 'usepackage' lines and other preamble
lines, so read the documentation carefully).

So, you could add a 'meeting' class to that variable and when you need
to do an org file for meetings, just add #+LATEX_CLASS; meeting at the
top of your org file and your ready to go.

This is what I did for my 'work' class, which produces documents
that included my employers logo, branding colours, fonts, font sizes,
heading formats etc. Now when I need to produce a work document, I just
add the #+LATEX_CLASS: header and then just write a normal org file. I
actually had a number of these custom 'class' definitions. 

Really nice thing is that if I find something needs to be tweaked or
changed, I just have to fix the org-latex-classes and related
definitions and know that if I re-export any of my org files that use
them, they will all get the fix (no need to edit each individual org
file to apply the fix).


-- 
Tim Cross



Re: Idea for handling timezones

2021-04-03 Thread Tim Cross


Greg Minshall  writes:

> Russell,
>
>> I would not suggest using UTC. I believe one of the reasons timestamps
>> didn't include TZ information was to keep them short and human
>> legible. Solutions with overlays to change a timestamp reduce the
>> usefulness of the plain text reading of Org (ie: less, grep,
>> etc). Storing timestamps with UTC is really a shortcut for the
>> computer, not the user.
>
> i wonder if this is perhaps another place where "org mode as simple
> text" conflicts with "org mode to solve difficult problems".  that comes
> up from time to time (using dollar signs as delimiters for math is one
> recent example, another is "-" being "filled" into column one and taken
> as an item in a new list).
>
> it's a hard line to straddle.
>

I think you are correct. There are fairly frequent issues associated
with timestamps and much of it is due to the tension between trying to
have something which is human friendly and having something which lends
itself to being used for calculations or in an environment where the
timezone regularly changes (i.e. from someone who travels a lot).

Adding timezone infomation to timestamps by default is not difficult.
Org uses Emacs' time handling functions under the hood and supports
setting custom timestamp formats. If I was someone who regularly moved
between timezones, I would definitely modify the default format to
ensure timezone information is recorded with the timestamp. This would
at least let the user know what timezone was being referenced when the
timestamp was created and what needs to be done to (even mentally)
convert it to whatever the current timezone is.

For any calculations involving timestamps, the only sane way to do
things is to convert all timestamps to UTC, perform the calculation and
if necessary, convert back to localtime for final result. It was
mentioned elsewhere in this thread that issues associated with DST
changes are OK because they occur early in the morning and not much
happens around then. However, this ignores use cases that depend on
calculation of time intervals. Provided all calculations are performed
using UTC, everything should work as long as timestamps include TZ info.

I don't like the idea of having a header variable which records the
timezone. I think this will be a source of errors and confusion and just
won't work well for many setups (for example, people like me who have
many org files with timestamps in them).

I feel a better result would be to

- Update default timestamp format to include timezones

- Add a new function which would either (or all of)
   - Convert an existing timestamp to a specified tz
   - Convert all timestamps in a file to a specific tz
   - Convert all timestamps in agenda files to a specific tz
   - Convert all timestamps in all org files to a specific tz
  User can then run the function as required (for example, after
  changing timezone location). 

- Ensure all exporter back ends support the ability to set an export
 timestamp function, allowing changing/stripping of TZ data during export
 as you frequently want a more concise format in exported documents. I
 believe this is already supported to some extent. 

The other things we could probably add is a timestamp display
tooltip/overlay which could be defined to popup when the mouse/cursor is
on the timestamp and which would display the timestamp in some timezone
which the user could specify as an option and which defaults to whatever
the local timezone is at the time. Then, when you see a timestamp which
is in lets say US EDT and your in Tokyo, moving your cursor or placing
your mouse on that timestamp would display a tooltip showing the local
time equivalent. 

-- 
Tim Cross



Re: First steps exporting to tex

2021-04-03 Thread Tim Cross


Ypo  writes:

> Good morning
>
> After reading your interesting advices, I've decided to start my path through 
> LaTeX. I have been some hours trying to start, with little result, but I
> hope that once established a *workflow* the results will come and the new 
> invested time will be directed just to get better and better results.
>
> My doubts:
>
>  a. As first step for my workflow, it seems convenient to use a "template" 
> with the LaTeX preambles. So maybe the many existing LaTeX
>  templates can be used quickly with orgmode. I found several options and 
> opinions. Which one is the best way?
>
> 1  #+SETUPFILE: template.setup -> doesn't seem the ideal way, because the 
> template.setup file must be modified adding #+latex_class to each of
>  the lines.
> 2  template.tex -> this could be added to the SETUPFILE: #+LATEX_HEADER: 
> \input{template.tex}. But it seems to have no effect on the PDF
>  output. BTW, I can't use emacs HOME path (~/) in the input header, like 
> \input{~//export//template.tex}. This is my template.tex file content: 
>  \usepackage{fancyhdr}
>  \thispagestyle{fancy}
>  \lhead{\includegraphics[width=4cm]{jpg.jpg}}
>  \rhead{Student Name: Name\\
>  Student ID: 1234\\
>  Course: IDB 601 (Fall 2020)}
> 3 Another friend told me that .sty templates were the best way.
> 4 I see some people that create customized LaTeX classes and add the desired 
> class to the orgmode buffer.
> 5 Also we can see this intricate transformation of a LaTeX template into 
> orgmode. How to Migrate LaTeX Template into org-mode
> 6 ...
>
>  b. I think that in a good integration, every character shown on orgmode 
> should be exported into the PDF output. For example "CENTRE LINE
>  SYMBOL": ℄ 
>  How can this integration be done?
>
>  I have more doubts, but I will keep reading and trying to solve them
>
>  Best regards

Why do you think you need any of this for your 'first steps'. Start by
just writing your org file and exporting it to latex or pdf. Then, once
you have your first document, see what you think needs changing and come
back and ask advice on what you need to do to make the changes you want.
In your first document, don't use any latex commands, header options or
anything else - just write your document using standard org mode. 

Org already sets up a reasonable starting default. Once you know what
the default is, then we can discuss what you may need to change. For
many documents, you may not need to change much at all and you may not
need any templates - for example, you will likely want to change the
margin sizes (this is a common request) or you may want to see what some
of the other 'standard' latex document classes are like. All of this can
be achieved with just minor configuration of org mode.

The org export to latex only needs to be as complicated as you need it
to be. Org has variables which can be used to add/remove things from the
preamble and once you have those configured, you don't have to put
anything in the org file itself. Start simple and add as you find a need
rather than try to start with something complex which might not be
necessary.

-- 
Tim Cross



Re: Idea for handling timezones

2021-04-02 Thread Tim Cross


shironeko  writes:

> Hi everyone,
>
> I, like many others on this list, have to move between timezones quite
> frequently. As I gathered from the archive, it seems the main complexity in
> supporting timezones is the difficulty revolving the change of timestamp 
> format.
> So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be set at
> the start of the file like so
>
>   #+TIMEZONE: America/Toronto
>
> This specifies the timezone of all timestamps in the file. Together with it,
> there can be a function called e.g. org-shift-time, that shifts all the
> timestamp in the file to another specified timezone and updates the keyword. 
> Of
> course, care needs to be taken when dealing with dates without time, e.g. it
> should be treated as at time 00:00 when it is alone or as the start of a time
> range, and be treated as at time 24:00 when it is the end of a time range.
>
> Then there could be hooks that offer to run the function automatically when it
> detects the user's system or emacs is set to a different timezone as in the 
> file
> (e.g. when they open the file, or opens the agenda). This will make sure the
> timestamps always aligns with their current one (if they wish).
>

I'm sorry, but I don't like this idea. In general, I think it is the
wrong approach and not sophisticated enough to work with the
complexities associated with timestamps.

This is actually a very hard problem and not one which can be adequately
addressed with something this simple. Problems include

1. Timzone alone is not sufficient. Offsets from UTC change due to
daylight savings times etc.

2. You can easily have timestamps from different timezones in the same
org file

3. Storing timestamps in local time is problematic because of the
inherent ambiguity this can have (again, due to daylight savings times
and what occurs at the 'cut over' time).

4. Sometimes, you may want the timestamp to reflect the date/time as it
was when recorded and don't want it to 'change' because your now viewing
it in a different timezone etc.

Personally, I think timestamp 'storage' and timestamp 'display' need to
be treated separately. I also think all relevant information (timezone,
offset) need to be stored with the timestamp. I also think the
fundamental base timestamp should be stored as UTC, allowing all time
calculations to be consistent (free of daylight savings time changes).
The user can then manage how the value is displayed by setting timezone
and offsets as appropriate (with perhaps the default being the local
system settings or whatever offset/tz was stored with the timestamp
itself). 

It is very difficult to predict or understand all the use cases for
timestamps. Therefore, any scheme must be extremely flexible. Experience
has taught me that one critical component is that at the lowest level,
many problems are avoided if the value is in UTC. Problem is, UTC is not
terribly human friendly. Luckily, this can largely be automated for many
common use cases. Unfortunately, it does also mean that if you are
someone who frequently moves between many timezones, your situation will
be more complicated. 

ne of the most frustrating parts of working with timestamps is daylight
saving times. This causes complications at so many levels. In
particular, I hate the fact change over dates often change and more
often than not, those changes are based around politics and at the whim
of politicians, which makes programatic handling more complex than it
needs to be.

-- 
Tim Cross



Re: Including Email Address in the Reply in Mailing-list

2021-04-02 Thread Tim Cross


I have no issue with this suggestion and am happy to try and comply.

The challenge for many will be that they either

- need to remember to remove the email details manually (line/header
automatically added by mail client) while sorting out either

- how to modify mail client for all replies (may not be appropriate for
non-ML replies), or

- how to modify mail client for just ML replies

My personal belief is that if you subscribe to a public mail list, you
need to accept that your email address will be 'out there' - more
generally, over time, your email address is going to be harvested
regardless and your better off trying to improve filtering and spam
detection than any attempt to minimise the address appearing in archived
content on-line.

Off now to try and work out how to change the reply header in my mail
clients!

Husain Alshehhi 

> Hello all,
>
> I just noticed that some of us here, when replying, include the email of
> the sender of the previous email in the response as part of body of the
> email. This email address shows up in plain text in the mailing
> list[1]. This is certainly done without any ill-intentions, but that
> could cause the email address to receive quite a bit of spam if spammers
> crawl these pages.
>
> I suggest refraining from doing so, and instead use the name. Please let
> me know what you think.
>
> [1] this is an example: 
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00042.html


-- 
Tim Cross



Re: Font lock in org+elisp confused with ?\[

2021-04-01 Thread Tim Cross
I'm forwarding this to the emacs-orgmode list as this is something org
maintainers probably need to see.

On Thu, 1 Apr 2021 at 15:43, Arthur Miller  wrote:

>
> Is it me or is it a bug?
>
> When in org mode in an elisp block, this seems to confuse syntax
> checker:
>
> #+begin_src emacs-lisp
> (progn
>   (if (= (following-char) ?\])
>   (forward-char -1))
>   )
> #+end_src
>
> Identation seems to think it is one level extra, and it also shows as
> error. Same of course when testing for ?\[.
>
> It does evaluate correctly. Ordinary elisp buffer does not have problem
> with this, only when in code blocks in org-mode or elisp mode.I can send
> in some screenshot with errors if needed.
>
>
>

-- 
regards,

Tim

--
Tim Cross


Re: Using backticks for the inline code delimeter?

2021-04-01 Thread Tim Cross


Joost Kremers  writes:

> On Fri, Apr 02 2021, Tim Cross wrote:
>> Getting backticks to font-lock correctly is relatively easy. Getting the
>> exporters to understand the new syntax is more of a challenge
>
> Don't the exporters work off of some intermediate representation, like Pandoc
> does? I kinda thought that was what `org-element.el` was all about... 
>
> And of course I meant to type ~org-element.el~ there... :D

Yes, at least most of the core ones should. However, I would still
expect some surprises and of course there are no guarantees regarding
the contrib and other external ones. Despite attempts to abstract the
syntax to make it 'flexible', I would be surprised if there is not
functionality in some of the exporters which has implicit assumptions
regarding the syntax being used and is not isolated from such changes. 

Note that I'm not saying this cannot be done or even that is should not
be done. I just want to highlight that just making changes to how org
deals with it at the 'presentation' layer may not be sufficient and that
you would have to verify there are no unexpected side effects in any of
the exporters. If you wanted to keep backwards compatibility or make
using ` and alternative to ~, you would also need to decide/verify
things like `word~ (i.e. mixed delimiters) are handled correctly (i.e.
simple regex with alternatives would not be sufficient - would need to
be a match which allowed both but ensured matching values).

Of course, there is a big difference between making a change to org and
making a change to an individual's own org instance. So if we are
talking about how someone can hack their own org instance to use `
instead of ~, it can be much simpler as they don't have to worry about
the bits they don't use or backwards compatibility. The downside then
becomes just the hassle of maintaining your hacks over subsequent org
releases. One reason why I would probbly go with a method which just
changes how I input data. For example, I would define a function which
inserts ~ or if a region is marked, surrounds it in ~ and then just bind
that to a key, never using ~ or ` directly to mark text.

-- 
Tim Cross



Re: Using backticks for the inline code delimeter?

2021-04-01 Thread Tim Cross


Samuel Wales  writes:

> n.b. everybody knows better in this thread, but the docstring of
> org-emphasis-alist seemed to me like `test` + reload would fontify.

Getting backticks to font-lock correctly is relatively easy. Getting the
exporters to understand the new syntax is more of a challenge as is how
to deal with backwards compatibility so that all your existing org files
don't need to be modified.


-- 
Tim Cross



Re: About exporting

2021-04-01 Thread Tim Cross


Eric S Fraga  writes:

> On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
>> And there is a final thing which (for me) seem to work better in
>> latex-mode compared to org. That's jumping to the ``next error'' with
>> some key stroke. That's important, LaTeX's own error output it quite
>> poor, but jumping to error locations is vital.
>
> Yes, this is an issue I have as well.  And the fact that the error
> messages are for the LaTeX lines, not the org lines, so you end up
> sometimes having to look at the LaTeX code and then go back to the org
> file.  This definitely adds friction!
>
>> I would not be surprised if some of that is somehow supported by org as
>> well (for TeX), only I have not figured it out, or perhaps I was too
>> lazy to figure it out how. 
>
> No, I don't think there's anything (at the moment) to help with this.  I
> would love to be proven wrong, mind you!  Org always has more
> capabilities than I know...

the only small bit of help I've found is org-lint, which has helped me
find issues in the past. Doesn't help track down errors from *.tex ->
pdf etc, but often an error in the org file causes the errors in the
*.tex export.

Having said that, I find the most common cause of errors in the *.tex
export is due to in-line Latex in my org file. I rarely run into errors
due to export of 'normal' org content.

When I do run into problems, I just open the *.tex file in Auctex mode
and track it down that way. Usually, it isn't too hard to work out where
that relates back to the source org file. Being able to do that
semi-automatically would be nice, but I think something that would be
very difficult to implement. You would need something to parse the tex
error output, extract text which could be then searched for in the org
file. As mentioned, the problem is tex errors don't always contain that
information, so you would probably also have to parse the tex file and
then try to map that back to the corresponding part of the org file
(which assumes of course that it is the org data which has caused the
issue and not something relating to latex package or package
configuration).

-- 
Tim Cross



Re: Using backticks for the inline code delimeter?

2021-03-31 Thread Tim Cross


"Dr. Arne Babenhauserheide"  writes:

> George Mauer  writes:
>> - lists with dashes, org supports that just fine
>
> or stars (not possible with org) or plus (in org).
>
>> *bold text* with stars, again org already does this
>
> Note that this does not match markdown: Markdown uses *emphasis* and 
> **strong**.
>
>> `backtick code`, org doesn't handle this and actually uses the tilde as a
>> delimeter which is extra jarring since its a strikethrough in many chat apps
>
> tilde or equals.
>
> - list
> *bold*
> =code=
>
> Adding more syntax is a slippery slope, because then `foo` can never be
> used for anything else, and there is a limited amount of usable syntax
> elements.
>

Yes, I think this is potentially a bad idea. Org parsing is already slow
enough without adding yet more syntax and font-locking complexity.

I also suspect this is not as simple as just adding this to org parsing
- all backends and many contributed packages would likely also need to
be updated to understand the new syntax. So probably not a trivial
change and a change which is likely to have real impact wrt backwards
compatibility.

Part of the issue here is that there is no markdown 'standard'. There
are a number of markdown 'flavors' or dialects. Org is just another one
(and one of the older ones at that). 

-- 
Tim Cross



Re: Starting from 9.5, Org contrib will be distributed as a separate NonGNU ELPA package

2021-03-30 Thread Tim Cross


Allen Li  writes:

> Bastien  writes:
>
>> Hi all,
>>
>> starting from Org 9.5, org-contrib will be distributed as a NonGNU
>> ELPA package.  You will find it here: https://elpa.nongnu.org/nongnu/
>>
>> See for https://orgmode.org/list/87wnzfy60h@bzg.fr/ for context.
>>
>> Thanks,
>
> Will there be an overlapping period (and if not, can we add such a
> period)?  For example, have one release where org-contrib is still
> shipped, and the NonGNU repos are available.  That gives users such as
> myself a period to switch over without things breaking immediately.
>
> If I understand correctly, the current plan is that users using
> org-contrib will have their configs break immediately when they upgrade
> to 9.5, forcing them to do both the 9.5 upgrade and switchover to NonGNU
> simultaneously.  It's easier if we can first safely upgrade to 9.5, then
> switch to NonGNU repos, and in the next release org-contrib can be removed.

I agree an overlap would be useful. This will give maintainers of
'canned' configs, like spacemacs and doom time to update their setups.

However, just to clarify. As I understand it, after 9.5, there will no
longer be an 'org-plus-contrib' package. Those who now use
org-plus-contrib will need to update their config to install org (fro
ELPA) and org-contrib (from NONGNU ELPA). The good news is nothing will
break. When you do an update, there just won't be an updated
org-plus-contrib and you will remain on 9.5. Only after you have updated
your config will you get a version > 9.5.


-- 
Tim Cross



Re: Adding Quick Notes in Org-mode Agenda View Inserts then In Drawer in Reverse Order

2021-03-30 Thread Tim Cross
t my notes to HTML, exporters will ignore the
>LOGBOOK, and I would like to export my notes.
> b. Notes are ordered in reverse: newer notes are put first.
>
> Because of this behavior, I suspect that I am hijacking the notion of
> "status change notes" and using them as notes.
>
> My questions are:
>
> 1. Am I using the notes correctly in org?
> 2. If not, what is equivalence of adding quick notes into a task
>(ideally, with time stamp of sort)?
> 3. If yes, then how can I work around the limitations (a) and (b)?


-- 
Tim Cross



Re: About exporting

2021-03-30 Thread Tim Cross


Martin Steffen  writes:

>
> There is one case where I do _NOT_ use org for such documents (though I
> use org basically most things I do), and that is
>
>  collaborative editing,
>
> working together on a document (maybe shared by git), at least with a
> document of some amount of complexity and typesetting requirement.
>

Yes, this is still the big unresolved challenge. The sad truth is people
think editing using word and 'track changes' is a good way to do
collaborative documents. I found it was actually pretty bad once you had
more than 2 people working on the document. It really only worked well
if the collaborators worked in serial i.e. one after the other and you
had a single file which just had track changes on it.

My 'solution', which wasn't great, but which I still preferred to
fighting word and track changes, was to send out the document exported
as ascii from org, to each collaborator and told them 'just edit it,
don't worry about formatting, I'll fix that'.

I would then use diff on the returned ascii files to combine them back
into a single ascii file, convert that back to ork and then export the
final form in whatever format was required. This had a couple of
advantages and disadvantages -

Advantages were I had control over the final document. Was actually
useful to release PDFs stamped with 'draft' until agreement was reached
and then issue a single final document. It is amazing how much confusion
can exist in large organisations because multiple versions of some
document are floating around and people lose track of which was the
final version.

Other advantage was I simply didn't have to deal with word. Even doing
all the diff combining (using Emacs of course!) and re-formatting was
faster for me with org than fighting with word and trying to get a good
looking final word document which contains heaps of conflicting styles
etc. (dig into the metadata for a Word document which has been shred and
edited by multiple people and you will know what I mean!).

Disadvantages included some people just not being able to deal with
editing a plain ascii document - just too use to word processing and
found the whole process frustrating. Also, in some situations, people
hated giving up control of the document.

The other somewhat ironic disadvantage was that the organisation was use
to ugly and badly formatted word documents which had a heap of
organisation format 'policy' which you had to comply with (type of font,
font size, margins, line spacing etc. I had to 'uglify' the latex output
in order to make the documents look like other documents produced in the
organisation. This took a bit of effort, but at least once it was done,
I could re-use the setup.

Funny thing was, whenever I produced a document which was just produced 
with un-uglified Latex, I would typically get comments about what a nicely 
formatted
document it was. Nobody ever said that with documents which complied
with the organisation's 'policy'!

-- 
Tim Cross



Re: org-adapt-indentation not honored prior to Org 9.4?

2021-03-29 Thread Tim Cross


Kyle Meyer  writes:

> Mike Kupfer writes:
>
>> Over the weekend I upgraded my Emacs from 27.1 (Org 9.3) to 27.2-rc2
>> (Org 9.4).  I noticed that Org mode behaves differently, even with
>> "emacs -Q".
>>
>> In 27.1, if I visit foo.org and type "* header RET", point is put in the
>> first column.  In 27.2, point is put in column 3.
>>
>> AFAIK, I'm not using electric-indent-mode; at least it's not shown in
>> the minor mode list in the modeline.
>
> electric-indent-mode has been enabled by default since Emacs 24.  If you
> run `C-h v electric-indent-mode` under emacs -Q, you should see that its
> value is t.
>
>> org-adapt-indentation is t in both Emacs 27.1 and Emacs 27.2.  Was there
>> a bug fix that went into Org 9.4 such that org-adapt-indentation is now
>> honored?
>
> Not that I'm aware of.  However, Org was changed to respect the
> electric-indent-mode value: d3e6b5800 (Make RET and C-j obey
> `electric-indent-mode', 2020-05-05)
>
> https://orgmode.org/list/877dxpazbo.fsf...@gmail.com/T/#u
>
>> Could the change in behavior be documented in the ORG-NEWS
>> file in Emacs?
>
> Here's what ORG-NEWS says under the 9.4 release:
>
> *** =RET= and =C-j= now obey ~electric-indent-mode~
>
> Since Emacs 24.4, ~electric-indent-mode~ is enabled by default.  In
> most major modes, this causes =RET= to reindent the current line and
> indent the new line, and =C-j= to insert a newline without indenting.
>
> Org mode now obeys this minor mode: when ~electric-indent-mode~ is
> enabled, and point is neither in a table nor on a timestamp or a link:
>
> - =RET= (bound to ~org-return~) reindents the current line and indents
>   the new line;
> - =C-j= (bound to the new command ~org-return-and-maybe-indent~)
>   merely inserts a newline.
>
> To get the previous behaviour back, disable ~electric-indent-mode~
> explicitly:
>
> #+begin_src emacs-lisp
> (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))
> #+end_src
>
> Alternatively, if you wish to keep =RET= as the "smart-return" key,
> but dislike Org's default indentation of sections, you may prefer to
> customize ~org-adapt-indentation~ to either =nil= or ='headline-data=.

Hi Kyle,

one thing I think might help (maybe too late) would be to put the
entries for both electric-indent-mode and org-adapt-indentation so that
they are together in the release notes as they do interact with each
other and often people stop looking once they see one and not the other
(they are currently a fair 'distance' apart in the file). 

I suspect we will see a few of these as the changes an interaction
between those two things are not terribly intuitive.

-- 
Tim Cross



Re: About exporting

2021-03-29 Thread Tim Cross
may need you to manually add line breaks or an
included image may need some size hints etc.  

> ODT: I take this one as a lower level solution than LaTeX, but it looks 
> easier to tame, and it even allows to use templates,  for example to make 
> reports in
> the workplace. Do you think it is worth focusing on ODT exporting? Could it 
> be a definitive solution to publish papers and books directly from orgmode?
> ODT exporting sends some error message to me, but at least I understand it.
>

I've never liked the ODT output. I find the documents I produce using
ODT to be 'uglier' than those with Latex. However, if I need to produce
the document in a format which allows others to edit it, ODT can be
useful. 

> HTML: I have seen some themes designed to export in LaTeX format using HTML. 
> Here we would have the "definitive tool": The power of LaTeX in the
> versatility that could give the use of different themes for different 
> purposes. But, do you think it could get, some day, the quality of a direct 
> LaTeX export?
> No errors by my side when exporting to HTML.
>

No, because they serve different purposes. Latex is superior in every
way when it comes to producing a PDF or a printed document. HTML is
superior when you want to display the content in a browser. HTML is
terrible when you want to print the output. 

I think it is a mistake to try and just focus on one export format. The
great benefit of org mode is that you can export in multiple formats
with minimal or no changes to the source. If you need to export in a
format which will allow others to edit the document, ODT is great, if
you need to export to publish on the web, HTML, if you need a PDF Latex,
if you need a presentation, either beamer or something like reveal. They
all have a role to play.

A better use of time is getting to know org and how it can be configured
so that you can setup your export environments with defaults which suit
your requirements. When I see people modifying *.tex files generated by
org, it is often because they have not worked out how to add the
additional packages or set the configuration for those packages in org. 



-- 
Tim Cross



Re: Shutting down Org ELPA: No new release of Org on Org ELPA after Org 9.5

2021-03-28 Thread Tim Cross


Thanks Bastien.

To clarify, does this mean org 9.6 will be the first version only
released via GNU elpa (i.e. bug fixes for 9.5 will still be released via
Org elpa e.g. 9.5.1)?

Tim

Bastien  writes:

> Hi all,
>
> over the years, Org ELPA at https://orgmode.org/elpa/ has been useful
> to make it possible to install Org and Org+Contrib as ELPA packages,
> but maintaining a separate ELPA space just for Org is not necessary.
>
> Org 9.5 will be the last release to be distributed on Org ELPA.  After
> 9.5, we won't use Org ELPA for new releases.  Past releases will still
> be available, though maybe not indefinitely.
>
> The Org package will continue to be available through GNU ELPA (from
> https://elpa.gnu.org/packages/) and a new Org-Contrib package will be
> available from https://elpa.nongnu.org/nongnu/.
>
> Only stable releases will be distributed through both GNU and NonGNU
> ELPA repositories.  For those who want to test the unstable version of
> Org, please install Org from Git:
>
> ~$ git clone https://code.orgmode.org/bzg/org-mode.git
>
> See https://orgmode.org/manual/Installation.html#Installation
>
> If you used Org ELPA and are affected by this change, please tell us
> if this change affects you.
>
> Thanks!


-- 
Tim Cross



Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command

2021-03-25 Thread Tim Cross


Uwe Brauer  writes:

>>>> "TC" == Tim Cross  writes:
>
>> Diego Zamboni  writes:
>
>>> I have seen differences in this behavior depending on the Emacs
>>> build. The emacs-mac port
>>> (https://github.com/railwaycat/homebrew-emacsmacport)
>>> seems to intercept certain Mac-specific keybindings such as C-space
>>> and C-M-space and gives them their "Mac meaning", e.g. to bring up
>>> Spotlight or the
>>> symbol chooser. I could never figure out how to disable this behavior.
>>> 
>>> Now I use emacs-plus (https://github.com/d12frosted/homebrew-emacs-plus) 
>>> and this no longer happens.
>>> 
>
>> Normally, you need to disable those 'shortcuts' at the OS level i.e.
>> under the keyboard shortucts item in macOS preferences panel. Problem is
>> any macOS shortcut will grab the keys before Emacs sees them. Not sure
>> how the emacs-plus version gets around this. 
>
> Right, it seems and issue of the OS shortcuts as C-space is for
> switching keyboards (US->spanish>etc etc).[1]
>
> Do you know how to change or disable them?
>

I'm not on a mac at present, but from memory it is under system preferences ->
keyborad -> shortcuts.




Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command

2021-03-24 Thread Tim Cross


Diego Zamboni  writes:

> I have seen differences in this behavior depending on the Emacs build. The 
> emacs-mac port (https://github.com/railwaycat/homebrew-emacsmacport)
> seems to intercept certain Mac-specific keybindings such as C-space and 
> C-M-space and gives them their "Mac meaning", e.g. to bring up Spotlight or 
> the
> symbol chooser. I could never figure out how to disable this behavior.
>
> Now I use emacs-plus (https://github.com/d12frosted/homebrew-emacs-plus) and 
> this no longer happens.
>

Normally, you need to disable those 'shortcuts' at the OS level i.e.
under the keyboard shortucts item in macOS preferences panel. Problem is
any macOS shortcut will grab the keys before Emacs sees them. Not sure
how the emacs-plus version gets around this. 



Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command

2021-03-24 Thread Tim Cross


Uwe Brauer  writes:

> Hi
>
> Does anybody know how to achieve the traditional binding of 
> C-space to set-mark-command on MacOS (for emacsformacos)?
>
> Shift arrow down works, but will not work for a lot of features in org
> mode.
>

Have you verified c-space is not being used by the macOS UI as a
shortcut for something like spotlight search?

I now use spacemacs, but when I used my own setup, I don't recall having
to do anything special to get this behaviour apart from disabling macOS
shortcuts. 

-- 
Tim Cross



Re: trivial software engineering'ish question: switching org's

2021-03-21 Thread Tim Cross


Greg Minshall  writes:

> hi.  i occasionally want to switch from the org package to a git
> version, then back again.  and, i want to avoid the dread "mixed
> installation".
>
> i'm wondering is there a way people do this other than simply
> installing/deleting the package version?
>

As I understand it, the critical part is when Emacs compiles the org
files to get the *.elc versions. Provided you do not have any org
functionality loaded during that compilation process, everything should
be OK. The 'mixed' versions problem arises because you go to compile a
different version and Emacs includes definitions already loaded from
another version, generating *.elc files with mixed versions. 

Once org is compiled, the critical part is having the org version you
want show up first in the load-path, so the problem becomes one of just
managing the load-path entries appropriately. You could just ensure the
version you want is higher in the load-path or you could go the
'paranoid' route and have code which removes the version you don't want
from the load-path.

In the past, what I've done is have the git version of org in a specific
directory which I build with a separate process from the command line
using the make recipes in the repository - essentially just configuring
and running make. I then have some code in my init.el file which sets
that version at the start of my load-path when I want to run it and
which I comment out when I just want to run the version installed by
package.el. I also use the use-package macro to load my org
configuration and have two different blocks for that - one loading the
git repo version and one loading the org-plus-contrib  version I
normally use. I just comment out the one I don't want to use. I probably
could write some elisp to automate this, but to be honest, I switch
between org versions so rarely, commenting/uncommenting parts of my
init.el file is easy enough.

I don't do any of that at the moment as I've not needed to run from the
git repo since I switched to spacemacs and the spacemacs setup already
has the necessary workflow to ensure new versions of org are compiled in
a clean environment. Have not yet thought about how I will need to add
git based org when using spacemacs. Suspect All I'll need to do is
adjust the load-path as part of the init to reference the git sources
before any org functionality is loaded.

-- 
Tim Cross



Re: Bug: crash exporing to html [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

2021-03-20 Thread Tim Cross
>  ("w3m" :store org-w3m-store-link) ("file+sys") 
> ("file+emacs")
>  ("shell" :follow org-link--open-shell)
>  ("news" :follow #[257 "\301\300\302Q!\207" ["news" 
> browse-url ":"] 5 "\n\n(fn URL)"])
>  ("mailto" :follow #[257 "\301\300\302Q!\207" ["mailto" 
> browse-url ":"] 5 "\n\n(fn URL)"])
>  ("https" :follow #[257 "\301\300\302Q!\207" ["https" 
> browse-url ":"] 5 "\n\n(fn URL)"])
>  ("http" :follow #[257 "\301\300\302Q!\207" ["http" 
> browse-url ":"] 5 "\n\n(fn URL)"])
>  ("ftp" :follow #[257 "\301\300\302Q!\207" ["ftp" 
> browse-url ":"] 5 "\n\n(fn URL)"])
>  ("help" :follow org-link--open-help) ("file" :complete 
> org-link-complete-file)
>  ("elisp" :follow org-link--open-elisp) ("doi" :follow 
> org-link--open-doi))
>  org-latex-format-headline-function 
> 'org-latex-format-headline-default-function
>  org-link-elisp-confirm-function 'yes-or-no-p
>  org-latex-format-inlinetask-function 
> 'org-latex-format-inlinetask-default-function
>  org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
>  org-html-format-headline-function 'org-html-format-headline-default-function
>  )


-- 
Tim Cross



Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

2021-03-20 Thread Tim Cross


Andreas Eder  writes:

> On Fr 19 Mär 2021 at 13:33, Eric S Fraga  wrote:
>
>> With respect to the topic at hand, I believe it's the result of the same
>> tendency that Excel users have of using spreadsheets (aka tables) for
>> everything, something I hate when I'm given some Excel sheet that I need
>> to modify and where entries are huge paragraphs.  The UI in Excel is
>> horrible for these types of tables.  I would hate to see org go in the
>> same direction.
>
> +1 for that
> Unfortunately I have to deal with this type of people at work.
>

In my world, I suspect project managers would be liked a lot more if
they had never discovered excel!

Funny thing, survived for years without the scourge of excel, but
noticed it creeping in more around 2007 or so, then by 2015 it was
everywhere - project plans, requirement specifications, software testing
and even software/API design documentation.

I didn't mind when the core of the document was still about linked cells
with calculated values which would change based on changes in various
cell entries - that is what spreadsheets are for. However, often now,
I'm presented with a spreadsheet (or workbook) with not a single
calculation or cell formula - it is just about formatting. In many ways,
workbooks are being treated like a poor persons slow inefficient
database with a really poor interface.

More than once, I've taken these spreadsheets and extracted the data
into an org file with headings, sub-headings, TODOs and lists, possibly
with a couple of clock tables and been far better off. In one project,
we were really lucky because there was multiple Emacs users and we were
able to get org used as the primary data format for managing the project
(we even used taskjuggler to generate the diagrams needed for steering
committee). Unfortunately, that is a very rare situation and most of the
time, we are forced to use excel simply because it is a format available
to everyone on every platform.

This I think is the key problem - MS Office and excel in particular have
become ubiquitous and now people think the way information is presented
in spreadsheets is the 'default' or acceptable way to format data (i.e.
tables with large columns cntaining paragraphs of data). IMO tables are
really only a good presentation format when you can see the whole table
in a page or screen. Once you need to navigate around large cells,
columns, rows, it is really just about navigation around the data and I
find is often less efficient or useful and navigation around a well
structured org file. Where excel has us beat is in sharing of
information and enabling others to add/update the data. Everyone has
access to excel or excel compatible software, hardly anyone uses org (as
a proportion of total users, doesn't mean org doesn't have a lot of users). 

-- 
Tim Cross



Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

2021-03-19 Thread Tim Cross


Eric S Fraga  writes:

> On Friday, 19 Mar 2021 at 08:58, Tim Cross wrote:
>> I am a little concerned about the expansion and addition of features in
>> org mode when there seems to already be a challenge with respect to
>> maintenance and bug fixing. Personally, I would prefer an org mode which
>> is consistent and reliable over one with large numbers of features that
>> is less stable and slower.
>
> +1 on this.
>
> With respect to the topic at hand, I believe it's the result of the same
> tendency that Excel users have of using spreadsheets (aka tables) for
> everything, something I hate when I'm given some Excel sheet that I need
> to modify and where entries are huge paragraphs.  The UI in Excel is
> horrible for these types of tables.  I would hate to see org go in the
> same direction.
>

Those excel 'workbooks' are the absolute worst. I sometimes wonder if
project managers would be more popular if they hadn't decided to use
that as their primary tool. The UI to navigate through those
spreadsheets is horrible.  

The other problem is that tables with large cells of 'paragraph' like
data are not terribly nice from an accessibility perspective. They can
be difficult to navagate and things like screen readers can find it
difficult to 'render' the content in a sensible manner i.e. where the
spoken representation 'makes sense'.

It has also been stated that the Latex exporter won't be a problem as
tabularx (and other Latex packages) will just handle this. Sadly, I don't think 
it is
that simple. I have used that package a lot over the years and there
have been times I've had to render tables with multiple columns and
rows. While the various latex table like packages do provide a much
better outcome for tables with more complex cell structure, it is rare
that you don't need to do a fair amount of tweaking to actually get good
looking complex tables. Handling a cell with a couple of lines may be
fine, but it is very easy to hit the limits of what the package can
handle without some tweaking. This is where I think things begin to fall
down. My suspicion is that the amount of work needed to make the Latex
exporter handle the majority of common use cases for this new syntax is
much larger and more complex than it seems and getting this to work
reliably and consistently will be extremely difficult. 

We can be pretty certain that if we introduce some additional syntax to
allow for multi-line cells and perhaps multi-row+multi-column cells, if
the exporters do not render good looking output for every use case, bugs
will be reported. I also have no idea how this will impact some of the
other exporters, such as odt, texinfo etc. 

I do think we can probably add additional functionality to make working
with more complex tables in org files somewhat easier from an editing
perspective. I do have some concern over the potential performance
impact, but in general, feel this is probably the easier part of the
challenge. 

> In many cases, I believe that a simple text based database format would
> be more appropriate.  I wonder if the time would be better spent
> providing native support for GNU recutils [1] in org instead.  It could
> even have a table like export...
>

That would be an interesting exercise. However, it does add another
dependency and in some ways breaks the 'everything as text' philosophy
(though I guess the last 'rendering' in the org file is still all text). 

To some extent, discussions like this remind me of the early days of the
web where tables were used as the primary formatting 'tool'. Remember
those horrible web pages which consisted of deeply nested tables? We
learnt pretty quickly what a bad idea that turned out to be.

I wonder if part of the issue here is with the different characteristics
of displays and formatted or printed output. Displays have the property
of being 'infinite' - a row can be as long as you like and a column can
be as high as you like. With the growth in large screens many users now
have windows far wider than the old 80 characters that were standard in
old terminals. This tends to make tables a more appealing 'layout'
facility as you can have a number of columns with multiple rows fitting
on the screen. However, now you have a new problem - how do you map this
very wide structure to a fixed width, relatively narrow, sheet of
paper? 

The advantage of 80 characters was that generally, you could fit that on
a standard sheet of paper. It is also a good width for reading, allowing
you to take in multiple 'blocks' of text at a time. Really wide text can
look ok, but many find such wide text more difficult to read as you have
to scan long lines and cannot easily take in a 'block' at a time.

I think there is probably some very good reasons multi-row cells were
not supported in org mode initially. I suspect the reasons are not
necessarily obvious until you try to implement such support. I could

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

2021-03-18 Thread Tim Cross


Timothy  writes:

> Tim Cross  writes:
>
>> In principal, it wold be great to be able to support multi-row columns.
>> However, I'm not sure how easily this can actually be implemented in a
>> consistent and maintainable manner.
>
> Mmmm, this of feels like something where you'll quickly learn how hard
> it is/isn't when you try to implement it.
>
>> From watching these discussions in the past, I think the big stumbling
>> block is how easily multi-row columns can be added and maintained in the
>> various export formats. Some are easy, like HTML, but others are less
>> so. In particular, I know from my many years working with Latex,
>> multi-row columns are not straight-forward. There are lots of edge cases
>> to deal with and it is hard to get a consistent result programatically.
>>
>> Proposals like this one can seem simple and straight-forward on the
>> surface. However, implementation is another matter. All of the exporters
>> will need to be updated to handle this new syntax and it will probably
>> take a fair bit of work to handle it correctly in just plain org files
>> (formatting, highlighting etc).
>
> Currently if you were to try this content with the proposed syntax,
> content is just put in the top left cell of the group. This seems like a
> reasonable fallback to me. Then for HTML we have colspan/rowspan, and
> for LaTeX there's \multicolumn and with the multirow package \multirow.
>
> FWIW just formatting would need to be updated for Org files.
> Highlighting is fine as is.
>
>> If this was something people were prepared to put the time into
>> implementing, I think it must be done in a completely separate feature
>> branch and would need to be fully tested (including all back end
>> exporters) before it can be merged into the mainline branch. It would
>> also be important to profile and ensure it does not have significant
>> impact on performance.
>>
>> I am a little concerned about the expansion and addition of features in
>> org mode when there seems to already be a challenge with respect to
>> maintenance and bug fixing. Personally, I would prefer an org mode which
>> is consistent and reliable over one with large numbers of features that
>> is less stable and slower.
>
> I appreciate this concern, but I do think that the ability to have
> multi-col/row cells is invaluable in many large tables, and so would be
> a very good addition to Org.

We can debate how easy or hard this is to implement indefinitely. What
is needed is for someone to implement a working version which is
consistent, reliable and provides expected results across all export
environments.

The devil is in the details and I suspect that once you start trying to
implement the feature is when many of those challenges become clear.

My view is 'go for it'. Just create a new feature branch and implment
the functionality in that branch. We can then try using it and see where
it works and where it doesn't. Once this is done, a call can be made as
to whether it should be implemented in the main code base
-- 
Tim Cross



Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

2021-03-18 Thread Tim Cross


Atlas Cove  writes:

> On 18/03/2021 14:26, Timothy wrote:
>>Interesting suggestion you have here.
>>On a related note, I wonder if you might have seen this thread I raised
>>a while ago: https://orgmode.org/list/87k0v361x9@gmail.com/
>>The discussion has died down (unfortunately), but the idea is still on
>>my mind.
>>
>>--
>>Timothy
>
> I'd like to propose to fold my discussion into yours.

In principal, it wold be great to be able to support multi-row columns.
However, I'm not sure how easily this can actually be implemented in a
consistent and maintainable manner.

>From watching these discussions in the past, I think the big stumbling
block is how easily multi-row columns can be added and maintained in the
various export formats. Some are easy, like HTML, but others are less
so. In particular, I know from my many years working with Latex,
multi-row columns are not straight-forward. There are lots of edge cases
to deal with and it is hard to get a consistent result programatically. 

Proposals like this one can seem simple and straight-forward on the
surface. However, implementation is another matter. All of the exporters
will need to be updated to handle this new syntax and it will probably
take a fair bit of work to handle it correctly in just plain org files
(formatting, highlighting etc).

If this was something people were prepared to put the time into
implementing, I think it must be done in a completely separate feature
branch and would need to be fully tested (including all back end
exporters) before it can be merged into the mainline branch. It would
also be important to profile and ensure it does not have significant
impact on performance.

I am a little concerned about the expansion and addition of features in
org mode when there seems to already be a challenge with respect to
maintenance and bug fixing. Personally, I would prefer an org mode which
is consistent and reliable over one with large numbers of features that
is less stable and slower.

-- 
Tim Cross



Re: How to get shell source blocks to read my profile?

2021-03-16 Thread Tim Cross
variables from the login process (as it is
the parent of all) and any variables exported by parent processes in the
process hierarchy (such as any exported as part of an interactive shell
which sourced .bashrc for example) or is defined and exported in a
parent (such as part of a shell script which then executes the command
which creates the child process.

So, in general, you don't want to run all or many of your processes as a
login shell. At the very least it is wasting resources and at the worst
it could actually cause confusion or break things because it is causing
things to be run multiple times which should only be run once.

I suspect some of the confusion here is being cause because of the
different model approach used by the Mac OS. On the mac, you actually
have at least two process trees (I'm not a mac expert, so it is possible
there are more than two - in fact I'm pretty sure there are, but for
explanation purposes). On the mac you have your login process tree
and your 'dock' (launcher) process tree. The dock process tree is not
rooted as the child of a login shell, so there is no sourcing of
.profile and it is not an interactive shell, so no .bashrc either. The
execution environment associated with processes it spawns (such as when
you run a command) only consist of the global system environment setup
by the system prfile in /etc/profile, /etc/paths and /etc/paths.d and
any environment variables created and exported by the process itself
(i.e. using the setenv command in your emacs init.el). Whether emacs is
run in terminal mode or in GUI mode has nothing to do with what
environment context it has. The context is determined by the environment
context of the process parent.

So a common way to ensure your .profile environment variables are
available in Emacs when it is run from the dock is to use a shell
wrapper script which first sources .profile to create and export the
variables in .pofile and then run emacs. Often you won't just make it a
login shell, but simply source .profile. It is this script which is
added to the dock and is executed to start Emacs, ensuring it has your
.profile variables set and exported to the child process, Emacs. In
turn, any child processes created by Emacs will also include this
environment context (such as wehn you open an emacs terminal, run M-x
shell or execute org source blocks). 

The other approach is to just add the variables you need using 'setenv'
i your emacs init.el file. Often, there are only a few additional
variables you want inside of Emacs and child processes it creates, so
adding them to your init.el file is not hard. The one which is most
often needed is updates to the PATH variable to add additional
directories to search for executable files. You can use setenv to do
this or you can use the exec-path package or you can do what I do, which
is add these additional paths to /etc/paths.d. I don't bother with the
wrapper script on the Mac. There are only a couple of additional
variables I need defined, so I set them in my init.el using setenv. 

-- 
Tim Cross



Re: How to get shell source blocks to read my profile?

2021-03-15 Thread Tim Cross


George Mauer  writes:

> Thanks a lot! The interactive/non-interactive was indeed the core issue. 
> Extra frustrating because it seems like supplying `--rcfile` does nothing if 
> you
> *do* use `-c` but *don't* use `-i`...ah ad-hoc cli design.
>

It certainly can seem rather ad hoc. However, it actually makes sense on
some levels. If you use -c your telling the shell to execute a command
and then exit. By definition, this is non-interactive. This is covered
in the manual.

Where it becomes confusing is when your mixing in different options as
some override others. So, provided you include -i with -c, it will be
forced into interactive i.e. -i overrides the non-interactive status
added with -c. If you add -s, telling the shell to read input from
stdin, you also override non-interactive status.

The other possible solution to your situation is to ensure
Emacs runs inside an environment which has all your exported variables
i.e. inside your login shell environment. There are a few ways to do
this, but probably the easiest is to create a script which opens a login
shell, then calls Emacs (may need to use open - not sure) and Emacs will
inherit your environment. Advantage is that processes you then spawn
from within Emacs will also inherit that environment. You then add this
script as the executable in the dock rather than calling Emacs directly.

One thing to watch out for is that if your also using oh-my-zsh, it
setups up some aliases with the name emacs which actually call
emacsclient. This can be confusing as it means running just 'emacs' in
the shell will run the alias and not actually run Emacs directly. Things
can be even more confusing as there are also multiple ways to install
Emacs on the mac and they are all slightly different with respect to how
they setup things.

What I find hardest with writing shell stuff is that I simply don't seem
to do it much anymore. My brain cache is just too small and when I find
it necessary to write a shell script again, all that knowledge has been
flushed! Once upon a time, many moons ago, I could write shell scripts
that used sed, awk, cut, uniq etc without even needing to look at the
man pages. These days, I have to check the bash man page just to
remember what the expr operators are!

--
Tim Cross



Re: How to get shell source blocks to read my profile?

2021-03-14 Thread Tim Cross
> unless one of the
> options were specified. I think each is named specific to each shell name but 
> oftentimes you chain them together in practice.
>

There is also a difference between interactive and non-interactive
shells. I suspect this is the root cause of your issue. The source block
being run are non-interactive.

--
Tim Cross



Re: How to get shell source blocks to read my profile?

2021-03-14 Thread Tim Cross
nv | grep GIM
>   #+end_src
>
>   #+RESULTS:
>
> That is *still* nothing!
>
> Sanity is restored slightly when I run
>
>   #+begin_src shell :results list
> bash --login -c env | grep GIM
>   #+end_src
>
> which *does* indeed visit ~.bash_profile~ but only slightly.
>
> What is going on, and is there a straightforward way in which I can get shell 
> block to read from a profile?


--
Tim Cross



Re: Culling org files (notion of Types, many small vs few big files)

2021-03-05 Thread Tim Cross


TRS-80  writes:

> On 2021-03-04 16:11, Samuel Wales wrote:
> I have some other custom agenda functions as well, for things like
> periodic reviews (in the GTD sense) and others.  Org's Agenda really
> is essentially just like a database query engine when you get right
> down to it (except storing in plain text of course).
>

I thinink I would agree with this. The agenda is a lotmore than just an
'agenda'. I tend to view it as a 'query result', which just displays my
query in different ways. sometimes it is similar to what most people
would think of as an agenda, but often it is 'something' completely
different.
--
Tim Cross



Re: org-capture-templates: %date is too long

2021-03-04 Thread Tim Cross


Uwe Brauer  writes:

>>>> "RP" == Robert Pluim  writes:
>
>>>>>>> On Thu, 04 Mar 2021 15:22:21 +0100, Uwe Brauer  
> said:
>Uwe> Sorry, you misunderstood me, this time string, inserts the time 
> string,
>Uwe> when I execute the capture, but I want to extract the time string, 
> when
>Uwe> the message was received. This is why I used
>Uwe> %:date
>Uwe> in my first attempt, that works but inserts
>Uwe> Tue, 2 Mar 2021 19:35:03 +0100
>
>Uwe> Which I find way too long.
>
>Uwe> Just
>Uwe> Tue, 2 Mar 2021
>
>Uwe> Would be fine or 02.03.2021
>
>Uwe> But not the hour, seconds etc
>
>> It looks like the %:date handling respects the
>> 'org-time-stamp-formats' variable, so if you can arrange for that to
>> be let-bound appropriately during the capture process, it might do the
>> right thing.
>
> Hm that variable is set to
>
> Its value is ("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
>
> So if I call with a prefix it inserts
> <2021-03-04 jue 21:19>
>
> But nothing like +0100
>
> I am not acquainted with let-bound (only with let)
>
> So are you saying I should may use defadvice to modify org-capture?

Capture templates allow inclusion of an arbitrary elisp expression with
%(EXP). You could try defining an elisp function which accepts %:date as
an argument (i.e. a string arg) and formats it using normal elisp date/time 
functions and
returns the result as a string and then call that function within your
template?

--
Tim Cross



Re: Culling org files

2021-03-04 Thread Tim Cross


TRS-80  writes:

> On 2021-03-03 16:59, Samuel Wales wrote:
> I have come to similar conclusion about "don't let org files get too
> big."  Besides agenda speed, I think it is just easier to
> conceptualize things when each file covers only a limited scope, trees
> are more shallow, etc.
>
> So, lately (last year or more), I have been trying a "many small (up
> to perhaps medium)" instead of "few big" files approach (along with
> some custom tooling) and it has been working /a lot/ better for me.  I
> really feel on top of things for the first time in a long time.  My
> agenda is not cluttered.  I can focus on important things, while not
> losing track of the rest, etc.
>

I agree with this. I have a similar approach. I consider the file system
and org files to be the initial 'structure' and have many smaller files
rather than a couple of very large ones. Only a subset of files play a
role in the agenda (I'm still experimenting with two different
approaches for this - one uses a couple of functions which can
dynamically change the agenda list and the other uses a naming
convention which is used as the basis of a search to determine what is
included in the agenda. Final rsult will likely be a combination).

My use pattern also constantly evolves as my requirements and priorities
change. It is and probably always will be, a work in progress!

--
Tim Cross



Re: Tips on maintaining history in Org Mode

2021-02-26 Thread Tim Cross


David Masterson  writes:

> Tim Cross  writes:
>
>> David Masterson  writes:
>>
>> For me, my TODOs are setup so that they record a date stamp for when
>> they were added and whenever they change state e.g. started, done,
>> delegated etc.
>
> So, you use progress logging.

Yes.

>
>> For non-TODO items, I will often put an inactive timestamp in the
>> heading title.
>
> Do your headings become busy?
>

Some would feel they are 'busy'. I always put the timestamp at the
beginning of the heading, so there is a regular pattern (not much
different from the leading heading stars) and I've just got use to it,
so I don't really see it now.

> What would you use to then make a list of all meetings you had last year?

For me, archiving is about data I'm unlikely to need again, but just in
case I do, it is in the archive. I rarely look at my archives. However,
when I do archive, I will usually archive into a 'year' file. So, to
find all the meetings held in 2015, I would open that archive file and
search for entries with the tag MEETING (I also have a tag for PHONE).

--
Tim Cross



Re: Tips on maintaining history in Org Mode

2021-02-25 Thread Tim Cross


David Masterson  writes:

> There are many ways of maintaining history in a group of Org files:
> 1. Archive within a file
> 2. Archive to a separate (archive) file
> 3. Special TODO types for history
> 4. Special TAG types for history
> 5. etc.
>
> My question is, if you have meetings/phone calls as TODOs, what is the
> preferred way to handle when they move into history so that, *much*
> later, you can easily produce a list of all of the meetings/phone calls
> with dates and times of them?  The issue (I think) is, when you mark the
> TODO as DONE, you lose the info of what the TODO was originally.
>

A lot will depend on your requirements.

For me, my TODOs are setup so that they record a date stamp for when
they were added and whenever they change state e.g. started, done,
delegated etc.

For non-TODO items, I will often put an inactive timestamp in the
heading title.

I also make extensive use of the ability to add timestamp entries as
part of capture templates - for exmaple, my notes and even the file of
bookmakrs (RUIs) I have.


--
Tim Cross



Re: 'false' list item

2021-02-21 Thread Tim Cross


Greg Minshall  writes:

> Tim,
>
>> If a line starts with a number, period and space, but that line is
>> within a paragraph (i.e. no blank line above), then I don't think it
>> should be interpreted as an enumerated list item. If this is what the OP
>> is referring to, I would argue it is a bug. If it is a 'paragraph'
>> starting with a number, period and space, then being interpreted as a
>> list item would be 'normal'.
>
> i know this isn't precisely the discussion, but i use *unnumbered*
> lists, and i most often have no blank line separating the list from the
> paragraph above (or, indeed, below).  i could get used to a modified
> requirement, to reduce the false positives, but, would want heads up
> (or, maybe, sigh, an option?).
>

There is no plans to change anything as far as I know. What I wrote was
mainly to show why we have the situation and that any proposed solution
has its own drawbacks.

Bottom line, we cannot easily prevent the 'false' list item issue
without introducing either other issues or adding some additional syntax
to indicate list items, which defeats the 'plain' aspects which many
appreciate in org. Even the proposed 'solutions' still suffer from false
positives.

The question is probably, how can we 'flag' possible false positives in
a convenient manner. For example, it has been suggested that some form
of highlighting for list elements might make it easier to spot a false
element lurking in a paragraph of text. this could possibly be useful,
but I also worry about adding more font-locking and highlighting due to
the potential to degrade performance further. We already have people
running into issue with performance in large org files.



--
Tim Cross



Re: 'false' list item

2021-02-21 Thread Tim Cross


Samuel Wales  writes:

> perhaps if there is no blank line above or below, then it could be not a list.
>

Initially, that was my thought as well. Unfortunately, it isn't quite
that straight forward. Consider the list

 1. Item 1
 2. Item 2
 3. Item 3

The second item has no blank line above or below, but it is a list item.
With the blank line approach, the list would have to be

 1. item 1

 2. item 2

 3. item 3

which I doubt many would like. What I guess is really needed is a list
'environment' - once you see the first list item, following a blank
line, your in a list environment until the next blank line. However,
then, if you have list items which are multi-line items, you cannot have
a blank line between items as that would signal a new list environment.
Personally, if the items are longer, visually, I do like a blank line
between the items. So now either we need to add some sort of list
'marker' or we need something else, such as saying a list must be
indented further than the surrounding paragraphs i.e. if you had (using
loren ipsum for text)

-
Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non
orci commodo lobortis. Proin neque massa, cursus ut, gravida ut,
lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam
tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede.
Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus
neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus.
Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat.

1. Mauris ac felis vel velit tristique imperdiet.

Pellentesque dapibus suscipit ligula. Donec posuere augue in quam. Etiam
vel tortor sodales tellus ultricies commodo. Suspendisse potenti. Aenean
in sem ac leo mollis blandit. Donec neque quam, dignissim in, mollis
nec, sagittis eu, wisi. Phasellus lacus. Etiam laoreet quam sed arcu.
Phasellus at dui in ligula mollis ultricies. Integer placerat tristique
nisl. Praesent augue. Fusce commodo. Vestibulum convallis, lorem a
tempus semper, dui dui euismod elit, vitae placerat urna tortor vitae
lacus. Nullam libero mauris, consequat quis, varius et, dictum id, arcu.
Mauris mollis tincidunt felis. Aliquam feugiat tellus ut neque. Nulla
facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et
dictum nunc justo sit amet elit.
-

the 1. line is not a list, but

-
Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non
orci commodo lobortis. Proin neque massa, cursus ut, gravida ut,
lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam
tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede.
Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus
neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus.
Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat.

1. Mauris ac felis vel velit tristique imperdiet.

Pellentesque dapibus suscipit ligula. Donec posuere augue in quam. Etiam
vel tortor sodales tellus ultricies commodo. Suspendisse potenti. Aenean
in sem ac leo mollis blandit. Donec neque quam, dignissim in, mollis
nec, sagittis eu, wisi. Phasellus lacus. Etiam laoreet quam sed arcu.
Phasellus at dui in ligula mollis ultricies. Integer placerat tristique
nisl. Praesent augue. Fusce commodo. Vestibulum convallis, lorem a
tempus semper, dui dui euismod elit, vitae placerat urna tortor vitae
lacus. Nullam libero mauris, consequat quis, varius et, dictum id, arcu.
Mauris mollis tincidunt felis. Aliquam feugiat tellus ut neque. Nulla
facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et
dictum nunc justo sit amet elit.
---

the 1. is a list item i.e. being indented compared to surrounding text makes it
a list item. Any further lines indented to that level or more (for sub
lists) are also considered part of the list, until the next blank line.

The problem with this of course is that if you have a sub-heading which
only has a list of items, there is no surrounding text within that
section, so how would you identify it was a list?

The issue is, if we decide this is a bug, can we fix it? Is it a bug or
is it just an accepted limitation of the org document format and what we
have to do is ensure either no line starts with a '1. ' or we use
something like a unicode character so that it doesn't look like a
number+period+space and therefore not a list item?

--
Tim Cross



Re: 'false' list item

2021-02-20 Thread Tim Cross


Kyle Meyer  writes:

> Juan Manuel Macías writes:
>
>> If a line in a paragraph starts with a digit (or letter) + period +
>> space, Org misinterprets that as a list item. I almost always notice
>> this only when I export my document, which is a nuisance.
>>
>> I wonder if there is any standard solution to that, or if I'm missing
>> something... All that occurred to me is this "preventive" solution,
>> using `highlight-regexp':
>
> It seems that your approach would do a good job of helping you catch
> cases that you don't want to be treated as lists.  I'm not aware of any
> related functionality in Org, so I don't think you're missing something
> there.
>
> Once you know that there is a particular spot that you want to prevent
> from being interpreted as a list, you could add a zero-width space in
> front of it:
>
> (info "(org)Escape Character")
>
> I'm not sure if that's the sort of solution you're asking for, though.

If a line starts with a number, period and space, but that line is
within a paragraph (i.e. no blank line above), then I don't think it
should be interpreted as an enumerated list item. If this is what the OP
is referring to, I would argue it is a bug. If it is a 'paragraph'
starting with a number, period and space, then being interpreted as a
list item would be 'normal'.

--
Tim Cross



Re: state of the art in org-mode tables e.g. join, etc

2021-02-20 Thread Tim Cross


Greg Minshall  writes:

> John,
>
>> Is there a state of the art in using org-tables as little databases
>> with joins and stuff?
>
> i have to admit i do all that with an R code source block.  (the dplyr
> package has the relevant joins, e.g. dplyr::inner_join().)  and, in R,
> ":colnames yes" as a header argument gives you header lines on results.
> (maybe that's ?now? for "all" languages?)
>

For really complex joins and ad hoc queries, I would do similar or put
the data into sqlite. For more simple ones, I just define a table which
uses table formulas to extract the values from the other tables - the
downside being the tables need to have the same data ordering or the
formulas need to be somewhat complex. Provided the tables have the same
number of records in the same order, table formulas are usually fairly
easy.

I did think about writing some elisp functions to use in my table
formulas to make things easier, but then decided I was just re-inventing
and well defined database solution and figured when I need it, just use
sqlite. However, it has been a while since I needed this level of
complexity, so perhaps things have moved on and there are better ways
now.

--
Tim Cross



Re: Turning off all indentation in 9.4.4

2021-02-17 Thread Tim Cross


Kyle Meyer  writes:

> TRS-80 writes:
>
>> On 2021-02-04 12:45, Kévin Le Gouguec wrote:
> [...]
>>> ORG-NEWS provides these hints:
>>>
>>>> To get the previous behaviour back, disable ~electric-indent-mode~
>>>> explicitly:
>>>>
>>>> #+begin_src emacs-lisp
>>>> (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))
>>>> #+end_src
>>>>
>>>> Alternatively, if you wish to keep =RET= as the "smart-return" key,
>>>> but dislike Org's default indentation of sections, you may prefer to
>>>> customize ~org-adapt-indentation~ to either =nil= or ='headline-data=.
> [...]
>> Unfortunately, unless I am doing something wrong, none of these options
>> seem to really restore the previous behavior.  I have set
>> ~org-adapt-indentation~ to ~'headline-data~, and now pressing RET goes
>> to column 0.  However, unfortunately, TAB now no longer jumps to the
>> indentation level of the previous block (for example, so I can insert a
>> code block or other block structure into a plain list at the correct
>> level).
>
> I think you're talking about the following behavior.
>
>   * a
>   foo
>
> With org-adapt-indentation at nil (or the new headline-data value), foo
> doesn't get indented.  This behavior is not new to 9.4.  If you try with
> 9.3.8 and org-adapt-indentation is set to nil, it also will not indent.
> Step through org--get-expected-indentation to see how the different
> values of org-adapt-indentation are handled.
>
> So, if I'm reading your preferences correctly, it sounds like you want
> just the first suggestion in the above snippet, leaving
> org-adapt-indentation at its default value:
>
>   (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))

I think it might be slightly more complicated.

For me, here is what I would like

1. Draws and planning data indented according to the headline level
(i.e. headline-data)

2. No indentation on 'normal' lines UNLESS I indent the first line of
the paragraph/block. Then, once I do indent that first line, after
hitting return, I can hit tab and it will indent to the same level as
the proceeding line.

I thought this was the behaviour I use to have before org was updated to
comply with electric-indent mode. I could be wrong.

Currently, if I have org-adaptive-indent set to 'heading-data, if I
manually indent a line, I cannot indent subsequent lines to the same
level. Tab does nothing and I have to hit spaces.

I need to go back through the possible combinations to make sure I
didn't miss something. However, it seems I can have drawers/planning
lines indented to the headline level with org-adaptive-indent set to
heading-data, but then cannot indent individual paragraphs/blocks inside
the heading with tab or I set org-adaptive-indent to nil and manually
indent the draw/planning lines and then can manage content indentation
as I use to.

None of this is critical as it is really just aesthetics (i.e. does not
affect exports), but it did seem to be more DWIM before than it is now.

--
Tim Cross



Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

2021-02-16 Thread Tim Cross


Samuel Wales  writes:

> hi tim,
>
> tanks for your replies.
>
> 1.  the same problem occurs without any * in the buffer.

It will occur with any of the markup special characters e.g. *, =, _, +, /

>
> 2.  the emphasis regexps are supposed to be limited to a few lines.

Are they? What is 'a few'? This also won't work if you use
visual-line-mode and don't use auto-fill (as your paragraphs are then
just one long line).

>
> 3.  they are also supposed to not try to match dissimilar delimiiters.
>

Not quite sure what you mean here.

> the problem is that
>
> hi =something
>
> stops all emphasis of all types in the entire rest of hte bguffer even
> if the buyffer contains many lines.  this sems unusual to me.
>
> it does not break anything befofre it.
>
> so i think your hypothesis of what i am talking about might possibly
> not match what i am talking about at all.
>

I'm not disagreeing with what your saying. I think the reason the rest
of the file doesn't get parsed correctly is because the single markup
character has made the syntax inconsistent and broken.

The problem is I don't think there is a good fix for this which doesn't
introduce other problems. If the regexp which does the matching is
supposed to limit its search to just a specific number of lines, then
perhaps it is broken. However, I'm not sure what 'a few lines' really
means (2?, 5?, 10?). I also know from past experience that trying to
define font-lock matches which work in such a way is complex, error
prone and often results in a considerable performance hit.

Bottom line, if you want to use the characters reserved for markup
purposes as just plain characters, you have to somehow quote them or
mark them as being 'verbatim' characters. I do think it would be useful
to have something in the manual on this under the markup section.

--
Tim Cross



Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

2021-02-16 Thread Tim Cross


Samuel Wales  writes:

> to answer your question: i expected it to just skip the non-emphasis.
> not emphasizing the rest of the buffer seemed quite unusual.
>

I guess the problem is the same - how does org know when it is just a *
and when it is the beginning of some emphasis text? We could make it
that such markup only works on words, allowing the code to only consider
two * as emphasis if there are no spaces, otherwise treat as just a *,
but that would be inconvenient when you want to emphasis a phrase or a
couple of words. We could change the regexp to only consider it an
emphasis block if both markers are on the same line, but again,
potentially inconvenient and it would fail for those who use visual-line
mode where there paragraphs are just 1 long line.

In short, can understand what your saying, but not sure there is a
viable fix which doesn't have a heap of other consequences. Basically,
if you want to use the 'markup' characters as normal characters, you
need to either escape them or put them inside a verbatim directive.

--
Tim Cross



Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

2021-02-16 Thread Tim Cross


Samuel Wales  writes:

> hi tim,
>
> it isn't malformed, so definitely not looking to be told it's
> malformed.  it is just text that is not emphasis.
>
> if you think the function works as expected by skipping the rest of
> the buffer, then never mind.
>
> i was, in that case, just emphasizing that the code floating around
> that is used to fontify the agenda is going to break.  so nm.
>

OK, that makes more sense. I guess you need to escape the * e.g. \* to
turn off its 'special' meaning or put it between = to make it a
'verbatim' value. To be honest, I've never run into this
issue, but I tend to not use '*' in my text unless it is for emphasis.

--
Tim Cross



Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

2021-02-16 Thread Tim Cross


Samuel Wales  writes:

> in fundamental mode [to eliminate any extra stuff]:
>
> ===
> hi
> /hi/
> hi =test
> hi
> hi
> hi
> /hi/
> hi
> *hi*
> hi
> hi
> hi
> ===
>
> m-: (org-do-emphasis-faces nil) RET
>
> everything after =test does not get emphasized.
>
> there is code floating around that calls hte function directly instead
> of via font lock.  so even if font lock or org mode forgive this, that
> code does not seem to.  and idk whether it is forgiven or if there are
> unintended consequences.
>
> e.g. to emphasize in agenda.  which, not sure why it isn't?

I'm not clear on what you are expecting/wanting here. If you have badly
formed markup, syntax highlighting and other functions can be expected
to fail.

Are you expecting something more informative, like an error message
saying you have an unterminated emphasis marker or similar? If so, while
it might be possible, I suspect it would come at a high cost from a
performance perspective, especially in large org files. For example, at
what point do you decide the closing marker is missing rather than just
a little further along? At what point do you begin doing the checking -
after typing the first marker, after the first character, after the
first space (noting that all this checking comes at a performance cost)?

What does org-lint tell you when you have such malformed markup in your
document? Would that be sufficient to track down issues when they occur?
If org-lint is not picking it up or is not providing enough detail to
help resolve the issue, perhaps tweaking it would be worthwhile.

--
Tim Cross



Re: Turning off all indentation in 9.4.4

2021-02-14 Thread Tim Cross


TRS-80  writes:

>
> I have been struggling with this as well.  After reading this email, I
> gave it another try.
>
> Unfortunately, unless I am doing something wrong, none of these options
> seem to really restore the previous behavior.  I have set
> ~org-adapt-indentation~ to ~'headline-data~, and now pressing RET goes
> to column 0.  However, unfortunately, TAB now no longer jumps to the
> indentation level of the previous block (for example, so I can insert a
> code block or other block structure into a plain list at the correct
> level).
>

I can report I'm seeing the same behaviour. While now I only get indent
after a heading, I cannot hit tab to indent to the same level as the
last line to insert things like a code blcok or even a new paragraph at
the same indent level.

--
Tim Cross



Re: [PATCH] tweaks to ox-html style

2021-02-12 Thread Tim Cross


Jens Lechtenboerger  writes:

> On 2021-02-12, Kyle Meyer wrote:
>
>> TEC writes:
>>
>>> Hi All,
>>>
>>> This is just some tweaks to the styling in ox-html that I think may
>>> appeal (and prevent ridiculously long lines on non-small displays, which
>>> are an issue for legibility).
>>>
>>> I also took the opportunity to remove the (obsolete) CDATA strings and
>>> make the CSS more consistently formatted. If you don't want this to
>>> get its own commit, please just squash it.
>>>
>>> Style changes:
>>> - Restrict max content width, and centre
>>> - tweak styling of source code blocks
>>
>> I'm sure there are plenty of opinionated ox-html users on the list.  Is
>> anyone willing to provide feedback on this series?  Please don't assume
>> you need commit access to provide reviews.
>
> Hi there,
>
> I do not know why the CDATA lines exist.  I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.
>
> Patch 0003 is about whitespace fixes.
>
> Patches 0002, 0004, 0005 change defconst styling.  I don’t have a
> strong opinion here.  However, if they are changed now, what about
> turning them into defcustoms?  Then each of us would be entitled to
> their own opinion ;)
>
> The docstring for org-html-head-include-default-style says that
> org-html-style-default (a defconst proposed to be changed here)
> should not be changed.  Why not?
>

I think I pretty much agree here. IMO I think all the CSS styling in an
export should be defined with defcustom. CSS has come a long way since
the original HTML exporter was written and I think it is best to put
this power in the hands of the author. I realise some of this CSS
styling can be complex if we want good looking HTML exports and making
it available to be changed by the user could result in an increase in
issues relating to inconsistent or ugly output, but I think provided the
defaults are good, this risk is warranted.

My only question is whether we should continue to modify the current
html exporter or whether it would be better to rename the existing
exporter as xhtml exporter and do a new clean html exporter that is just
html5 and css3 and which does not attempt to be xhtml compliant?

Others have mentioned on the list that they believe it is important to
keep xhtml compatibility. This would satisfy that requirement and at the
same time, enable a new html exporter that can take full advantage of
changes introduced with html5 while keeping the exporter smaller and
cleaner (and easier to maintain).

BTW I think it would be nice if the html export was able to produce/use
a separate CSS file rather than in-line styles. This would make it
easier to drop exported HTML files into existing sites with custom
styles or update the look of exported files without needing to re-export
or manually edit. The complication is with exporting of HTML snippets,
where you probably want in-line styles.

--
Tim Cross



Re: OT: M-S-$ Not Working

2021-02-10 Thread Tim Cross


Maxim Nikulin  writes:

>> Were you able to get any assistance with this on the Emacs devel list?
>
> There was a thread in 2009, no results however. Unsure if it reasonable
> to raise the question again without a proposal how to solve the problem.
>
> https://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00031.html
>

I think it would be worth raising again. There has been significant
changes since 2009 (that message was prior to Emacs 23 release),
especially with respect to CJK, MULE, UTF-8 and input methods. It is
possible new solutions are now available.

--
Tim Cross



Re: OT: M-S-$ Not Working

2021-02-06 Thread Tim Cross


Maxim Nikulin  writes:

> On 06/02/2021 13:28, Tim Cross wrote:
>>
>> In general, standard Emacs key bindings are robust and reliable. If a
>> standard key binding like M-S $ doesn't work, first step is to try emacs
>> -Q.
>
> Sorry, but I do not agree that key bindings are robust in emacs. I use
> English and Russian keyboard layouts. Last years most of application
> could handle shortcuts independently of active layout (E.g. Ctrl+C and
> Ctrl+V works for copy-paste even if Russian layout is currently chosen.)
> In Emacs, only Control + Latin C works, Control + Cyrillic S (the same
> physical key) is undefined. Location of punctuation symbols depends on
> active layout, "$" is absent in Russian layout at all. It is extremely
> inconvenient to switch to US layout before any shortcut. Emacs uses its
> own input methods, but it means that desktop environment should treat
> emacs in a special way in respect to keyboard layouts. I have a kind of
> solution, I found its variants in blog posts. It is quite tricky, so I
> do not consider it as reliable and suitable for any user.

As I'm limited by the weakness of only understanding one alphabet, I
don't have any experience of things once you move away from an 'english'
based alphabet. However, I do find it surprising there isn't a simpler
solution to switch between the different layouts in a consistent way
which updates key bindings to something appropriate. I've not seen many
editors with the same level of support for different alphabets and
writing direction as Emacs and there are many keyborad layouts which
don't include the '$' key. At the end of the day, it really just comes
down to mapping of key codes - the 'image' on the key itself (and even
the location) is largely irrelevant. I imagine 'live' switching between
different input methods could be very complicated, but making the
complicated easy is something Emacs tends to be good at.

Were you able to get any assistance with this on the Emacs devel list?
Like it or not, computers are very english centric (and US english at
that). Maybe the issues you have encountered just need to be highlighted
and for there to be someone able to assist to enable the situation to be
improved? It may be a simple as improving the mapping of key codes and
tweaking the key translation table to improve the situation? If you
haven't done so, I would encourage you to start a new thread on
emacs-devel where you outline your key binding issues. I have frequently
found solutions on blogs and other forums only to find later there is a
far easier solution. I would expect many Russian speaking users have
encountered the same challenges. The Emacs devs have always seemed
pretty open to improving support for different languages and character
sets and once they understand the issue, will typically respond with
improvements fairly quickly provided someone is will ing to help test
etc. The hard part is defining the issue - once it is understood, a
solution is often not too far away.

--
Tim Cross



Re: OT: M-S-$ Not Working

2021-02-05 Thread Tim Cross


Marcin Borkowski  writes:

> Hi Bo,
>
> I know your problem is resolved now, but in case you don't know, check
> also what `C-h c' does (and `C-h k' is also useful at times).  In
> general, spending 20 minutes on looking through what `C-h C-h' says
> might save you some trouble later;-).
>

This is good advice. I would add that if you find that Emacs does not
respond, even to say that the key is not bound or defined, it is
typically a sign that something in the environment e.g. window manager
or X (or Wayland) layer is not passing the key press through. These are
layers which are often overlooked and I've seen people spend hours
inside Emacs trying to work out what the issue is, only to later find it
is at a different layer (OS, windowing environment, window manager,
etc).

In general, standard Emacs key bindings are robust and reliable. If a
standard key binding like M-S $ doesn't work, first step is to try emacs
-Q. If that still does not work, odds are high it is an issue outside of
Emacs. Most common causes are WM shortcuts, modified input device
definitions (as seems to be the culprit here) and modified modmap
settings. Utilities like 'xev' can be useful here (not sure what wayland
has).

When I install a new system (regardless of platform, linux, mac,
windows), my first task is usually to remove or remap shortcuts. These
days, most environments use super, alt, meta and control based
shortcuts, many of which interfere with my Emacs. I rarely use super in
my Emacs key bindings, so often I remap useful WM shortcuts to use
super.
--
Tim Cross



Re: Free up C-c SPC/org-table-blank-field?

2021-02-04 Thread Tim Cross


Eric Abrahamsen  writes:

>> Does it actually need a key binding? I've never used it and just use
>>  to move to the next field, leaving the field blank.
>
> I assume it's meant for blanking a field you've already typed something
> into. But yes, I can't imagine it's a heavily-used command, and I
> suspect the C-c  binding is mostly mnemonic: "make this field
> contain only blanks".
>

I guess that makes sense, but not convinced the use of a valuable key
binding is justified given the need. Then again, others probably have
vastly different use cases to mine.

>>>>
>>>> What do people think about making it a no-op when not on a table
>>>> (letting it fall through to the global map), or putting it in a keymap
>>>> text property on tables, or otherwise not hogging the binding?
>>>
>>> In my view, the first would be fine, and the second also unless someone
>>> chimes in with a technical reason not to. For the last, perhaps `C-c
>>> C-SPC' would be an okay replacement, though I'd assume that would break
>>> some users' muscle memory in a surprising and unpleasant way.
>>
>> I'm not familiar with how this is all put together inside org mode.
>> If it is possible to configure things so that it is only bound when
>> inside a table and does not shadow other bindings for that sequence
>> outside a table, I think that would be a positive change. However, I do
>> also note that this is the type of change which tends to cause 'ripples'
>> and may have unexpected impact in other areas, such as other packages,
>> predefined or 'canned' emacs configurations etc.
>
> The way Org handles these situations now is to have a command that is
> named for its actual keybinding (eg `org-shiftmetaleft'), which then
> examines its context and dispatches to various other functions. That's a
> bit odd and not really how it's done in Emacs -- but I am not proposing
> we change this as it is pretty fundamental to how Org is set up and
> would wreck a bunch of stuff if it were changed.
>
> I thought Emacs might have some easy way to let a key event "fall
> through" to other keymaps, but I haven't been able to find anything
> immediately obvious. Maybe I can ask on emacs.devel...
>

I don't believe there is one. I think the basic model is a hierarchy of
key maps with bindings and the first match wins. I guess the only option
is to add a more sophisticated context test and only perform the action
if the context is inside a table cell. If not inside a table cell,
either perform some function which makes sense. It could be that on
loading, org checks to see if there is a binding and stores that as the
default action outside of tables or if we have some action which would
make sense, bind to that or keep it simple and have it defined as a user
option which defaults to a noop and allow the user to define something
if they want?

Since switching to spacemacs and its 'evil' key binding model, I've
become very aware of the dangers associated with modes that try to be
too clever when it comes to key bindings. I think they are really quite
a personal thing and best kept as simple as possible. In general, org
has been reasonably successful with its rather 'advanced' approach, but
there have been times I've found it frustrating. Smart key bindings are
great when they do what you expect, but when they don't

--
Tim Cross



Re: OT: M-S-$ Not Working

2021-02-04 Thread Tim Cross


Bo Grimes  writes:

> I beg your indulgence.  I am confident this isn't an Emacs problem, let
> alone an org problem, but my eyes hurt from searching for an answer,
> and this list, the only one I subscribe to, is populated with gurus.  I
> promise never to use it this way again.
>
> OS: PopOS 20.10, DE: GNOME 3.38.2 WM: Mutter
> GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
>
> M-S-$ does not spellcheck word.  It will work from the menu bar, and it
> will work if I drop into a tty and run Emacs.  Emacs gives no
> response in the minibuffer in the GUI when I press M-S-$. M-x
> describe-key M-S-$ does nothing. C-h b C-s 'spell' reveals that indeed
> M-S-$ is bound to spellcheck word. And other M-S- keys work like M-S->
> just fine.
>
> There has to be some keybinding outside Emacs taking precedence. I have
> gone through dconf-editor until my eyes bleed. Done gsettings
> list-recursively  org.gnome.desktop.wm.keybindings | sort | more and
> gone line by line.  I have done dconf dump / > dconf.dump and read
> through them all, in addition to checking PopOS' keybindings in
> Settings. And trying a different keyboard.
>
> Nothing in Tweeks, dconf, or Settings uses M-S-$, but I disabled
> anything that uses Shift anyway (nothing uses $). No joy. I don't want
> to rebind it for this machine only, nor do I want to go through the
> hassle of installing a different DM/WM.
>
> StackExchange, et.al are full of problems with the the M key, but not
> one specific keychord only.
>

Do you see the same behaviour if you run emacs -Q?

--
Tim Cross



Re: patch: ob-clojure improvements

2021-02-02 Thread Tim Cross


OK. As the patch is over 6 months old, it would be good if the original
author can confirm it is still the latest version and if not, re-send
the most recent version.

Christopher Miles  writes:

> <#secure method=pgpmime mode=sign>
>
> I checked this thread, seems the original first email of thread contains the 
> patch. And it's not merged into Org git yet.
>
> Tim Cross  writes:
>
> OK, will push it up the todo list. Where can I get the latest version of the 
> patch or has it been added into the org git repo?
>
> Christopher Miles  writes:
>
> <#!secure method=pgpmime mode=sign>
>
> Hi, Tim, popup this thread to request review. 
>
> Tim Cross  writes:
>
> I am also interested in ob-clojure and ob-clojurescript improvements. 
> However, right now, I'm a tad busy and haven't had time to review what has 
> been done. Hopefully, can make some time in the next month or so.
>
> Tim
>
> stardiviner  writes:
>
> agzam.ibragi...@gmail.com writes:
>
> There seems to be a bit of lack of interest for these things. But I'm sure 
> some people (myself included) would love to see these kinds of improvements.
>
> Yes, I rarely saw Clojurians in this mailing list.
>
> As I said before, I have never participated in contributing to Org source, 
> some guidance would be appreciated.
>
> Org Mode has contribution guide here 
> http://orgmode.org/worg/org-contribute.html#patches
>
> Should I keep building it and posting patches? Should I try to go 
> incrementally, one small change at a time, or should I just get everything 
> working first? If it turns out to be a bigger work, should I ask for 
> permission to work in a branch and get access to pushing things to it? Maybe 
> things just move slowly, because obviously you can't force maintainers to 
> drop everything and concentrate effort to get your things in. Maybe I just 
> have to be a little bit more patient?
>
> I think a complete work contains many patches should be better, Also write 
> testing if necessary.
>
> I remember ob-clojure.el code are mostly reviewed by Bastien Guerry. I 
> included him in Cc: in this email.
>
> On Sat, Jun 20, 2020 at 1:23 AM stardiviner  wrote:
>
> Glad to see your patch, really useful in some cases. Thanks.
>
> Ag Ibragimov  writes:
>
> Hi everyone, here's my attempt to add clojure CLI and babashka support for 
> ob-clojure.el - Adds a header parameter to override org-babel-clojure-backend 
> - Adds :args param (right now only used for clojure-cli)
>
> I have tested it with these minimal cases:
>
> #+beginsrc clojure :backend clj-cli :args "-Sdeps '{:deps {inflections 
> {:mvn/version \"0.13.2\"}}}'" (use 'inflections.core) (plural "word") #+endsrc
>
> #+beginsrc clojure :backend babashka :results output (range 10) #+endsrc
>
> Please let me know what you think. Any advice is appreciated, since I have 
> never contributed before. Thank you.
>
> – [ stardiviner ] I try to make every word tell the meaning that I want to 
> express.
>
> Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: 
> stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


--
Tim Cross



Re: Free up C-c SPC/org-table-blank-field?

2021-02-02 Thread Tim Cross


Kyle Meyer  writes:

> Eric Abrahamsen writes:
>
>> Hi all,
>>
>> The C-c SPC keybinding is pretty prime property (it's also, according to
>> Emacs conventions, meant to be reserved for the user, though I know
>> that's already out the window with Org),
>
> Based on my reading of (info "(elisp)Key Binding Conventions"), I think
> `C-c SPC` doesn't fall into the user's `C-c LETTER' territory but
> instead into the this group:
>
>   Sequences consisting of ‘C-c’ followed by any other ASCII
>   punctuation or symbol character are allocated for minor modes.
>   Using them in a major mode is not absolutely prohibited, but if you
>   do that, the major mode binding may be shadowed from time to time
>   by minor modes.
>

Agreed.

> But, either way, I don't disagree with what you say next.
>
>> and it's currently bound to `org-table-blank-field', which is useless
>> unless you... happen to be in a table. I don't use tables often (or
>> blank fields when I do), which means this binding is effectively just
>> removed.

Does it actually need a key binding? I've never used it and just use
 to move to the next field, leaving the field blank.

>>
>> What do people think about making it a no-op when not on a table
>> (letting it fall through to the global map), or putting it in a keymap
>> text property on tables, or otherwise not hogging the binding?
>
> In my view, the first would be fine, and the second also unless someone
> chimes in with a technical reason not to.  For the last, perhaps `C-c
> C-SPC' would be an okay replacement, though I'd assume that would break
> some users' muscle memory in a surprising and unpleasant way.

I'm not familiar with how this is all put together inside org mode.
If it is possible to configure things so that it is only bound when
inside a table and does not shadow other bindings for that sequence
outside a table, I think that would be a positive change. However, I do
also note that this is the type of change which tends to cause 'ripples'
and may have unexpected impact in other areas, such as other packages,
predefined or 'canned' emacs configurations etc.

--
Tim Cross



Re: patch: ob-clojure improvements

2021-02-02 Thread Tim Cross


OK, will push it up the todo list. Where can I get the latest version of
the patch or has it been added into the org git repo?

Christopher Miles  writes:

> <#secure method=pgpmime mode=sign>
>
> Hi, Tim, popup this thread to request review. 
>
> Tim Cross  writes:
>
> I am also interested in ob-clojure and ob-clojurescript improvements. 
> However, right now, I'm a tad busy and haven't had time to review what has 
> been done. Hopefully, can make some time in the next month or so.
>
> Tim
>
> stardiviner  writes:
>
> agzam.ibragi...@gmail.com writes:
>
> There seems to be a bit of lack of interest for these things. But I'm sure 
> some people (myself included) would love to see these kinds of improvements.
>
> Yes, I rarely saw Clojurians in this mailing list.
>
> As I said before, I have never participated in contributing to Org source, 
> some guidance would be appreciated.
>
> Org Mode has contribution guide here 
> http://orgmode.org/worg/org-contribute.html#patches
>
> Should I keep building it and posting patches? Should I try to go 
> incrementally, one small change at a time, or should I just get everything 
> working first? If it turns out to be a bigger work, should I ask for 
> permission to work in a branch and get access to pushing things to it? Maybe 
> things just move slowly, because obviously you can't force maintainers to 
> drop everything and concentrate effort to get your things in. Maybe I just 
> have to be a little bit more patient?
>
> I think a complete work contains many patches should be better, Also write 
> testing if necessary.
>
> I remember ob-clojure.el code are mostly reviewed by Bastien Guerry. I 
> included him in Cc: in this email.
>
> On Sat, Jun 20, 2020 at 1:23 AM stardiviner  wrote:
>
> Glad to see your patch, really useful in some cases. Thanks.
>
> Ag Ibragimov  writes:
>
> Hi everyone, here's my attempt to add clojure CLI and babashka support
> for ob-clojure.el
> - Adds a header parameter to override org-babel-clojure-backend - Adds :args 
> param (right now only used for clojure-cli)
>
> I have tested it with these minimal cases:
>
> #+beginsrc clojure :backend clj-cli :args "-Sdeps '{:deps {inflections
> {:mvn/version \"0.13.2\"}}}'"
> (use 'inflections.core) (plural "word") #+endsrc
>
> #+beginsrc clojure :backend babashka :results output (range 10) #+endsrc
>
> Please let me know what you think. Any advice is appreciated, since I
> have never contributed before. Thank you.
>
> – [ stardiviner ] I try to make every word tell the meaning that I want to 
> express.
>
> Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: 
> stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


--
Tim Cross



Re: bug#44824: 27.1; Org export as pdf and open file does not open it

2021-01-30 Thread Tim Cross


Lars Ingebrigtsen  writes:

> Eli Zaretskii  writes:
>
>>> This doesn't work:
>>> M-x shell RET xdg-open /tmp/test.pdf RET
>>
>> How about asking the xdg-open developers to help us figure out the
>> reason?  Or, failing that, debug xdg-open in the problematic
>> situations to find out what fails there and why?  E.g., could it be
>> that it fails because stdin/stdout is a PTY? what happens if you bind
>> process-connection-type to nil when starting the async subprocess?
>
> I'm unable to reproduce the problem at all -- all the various ways of
> calling xdg-open work fine for me (on this Debian bullseye laptop w/
> Gnome Shell).

For me, I get

M-! xdg-open /tmp/test.pdf works
M-x shell  xdg-open /tmp/test.pdf works
M-& xdg-open /tmp/test.pdf fails
M-x eshell  xdg-open /tmp/test.pdf fails

The two which fail do not report any error - just now pdf viewer open.

I also have no problems with org export menu when I choose export to pdf
and open.

This was on a Ubuntu 20.10, latest Emacs 27 (27.5.91), mate DE and
default shell zsh.

--
Tim Cross



Re: [PATCH] ox-md.el export code blocks using grave accents.

2021-01-30 Thread Tim Cross


I don't think this patch is correct.

There are no precise standards for markdown, but org states in the
manual that the version of markdown it supports is that defined at
http://daringfireball.net/projects/markdown - which uses the indentation
style for code blocks, not the  style. Note that there is the github
markdown exporter which does support the  style.

One of the problems with markdown is the differing flavours out there.
While  may be supported on sites like github and stackoverflow,
other sites only support the indentation style. We therefore need to be
somewhat conservative with respect to introducing changes as while we
may 'fix' things for some sites, we could easily break them for others.
Given there is a package which supports the  style code blocks, I
don't think modifying the existing markdown exporter is necessary.

>From your explanation, I suspect what you really need is to use the
github flavoured markdown package available as ox-gfm on MELPA rather
than the default ox-md package in org mode.

Note that I have no particular preference for the markdown style defined
on daringfireball.net and there has been past discussions on this list
regarding what flavour of markdown org should support, so I know there
are varying opinions in this area. My main point is that if we specify
in the manual that we support a particular flavour, then that is the
flavour of markdown we should support. In other words, if we are going
to add features/support for syntax not defined on the daringfireball.net
flavour of markdown, we would need to document what syntax we do support
and consider things like backwards compatibility for any changes introduce.

Rodrigo Morales  writes:

> This patch includes the following changes in =ox-md.el=
>
> + =org-md-example-block= now exports code blocks using triple grave
>   accents instead of four spaces of indentation. This has been done
>   for two main reasons:
>
>   1. To be able to include the language so that Markdown engines can
>  syntax highlight the content of code blocks. Syntax highlighting
>  can also occur when using indentation in some websites (see
>  [[https://meta.stackexchange.com/questions/184108][this]]. However,
>  this method doesn't work in all websites (I haven't found
>  information about this on Github.). Therefore, using grave accents
>  is more generic.
>
>   2. To be able to put the source code and the results of evaluation
>  in different code blocks. When using indentation, both the source
>  code and the results are shown in the same code block by Markdown
>  engines.
>
> + The variable =org-md-lang-export= is now included in order to map
>   Org Mode language names to Markdown language names.
>
> The file =mre.org= contains a minimal reproducible example; =mre.md= ,
> the resulting file when exporting using the current version; and
> =mre-patch.md=, the resulting file when exporting with the changes
> of this patch applied.
>
> The patch is shown below.
>
> #+begin_src dash :dir (progn default-directory) :epilogue ":"
> gunzip -c /usr/share/emacs/27.1/lisp/org/ox-md.el.gz > ox-md.el
> diff -u ox-md.el ox-md-patched.el
> #+end_src
>
> #+RESULTS:
> #+begin_example
> --- ox-md.el  2021-01-30 16:49:33.459042367 -0500
> +++ ox-md-patched.el  2021-01-30 16:48:40.232375347 -0500
> @@ -50,6 +50,14 @@
> (const :tag "Use \"atx\" style" atx)
> (const :tag "Use \"Setext\" style" setext)))
>
> +(defcustom org-md-lang-export
> +  '(("dash" . "sh"))
> +  "Alist mapping languages to the corresponding language names in Markdown."
> +  :group 'org-export-md
> +  :type '(repeat
> +   (cons
> +(string "Org Mode language name")
> +(string "Markdown language name"
>
>   Footnotes
>
> @@ -181,10 +189,24 @@
>"Transcode EXAMPLE-BLOCK element into Markdown format.
>  CONTENTS is nil.  INFO is a plist used as a communication
>  channel."
> -  (replace-regexp-in-string
> -   "^" ""
> -   (org-remove-indentation
> -(org-export-format-code-default example-block info
> +  (let* (language
> +  (org-language
> +   (plist-get (car (cdr example-block)) :language))
> +  (markdown-language
> +   (cdr (assoc org-language org-md-lang-export))) ;
> +  (content
> +   (org-remove-indentation
> +(org-export-format-code-default example-block info
> +
> +(if markdown-language
> + (setq language markdown-language)
> +  (setq language org-language))
> +
> +(setq content (replace-regexp-in-string
> +   "\\`" (concat "```" language "\n")
> +   content))
> +
> +(replace-regexp-in-string "\\'" "```" content)))
>
>  (defun org-md-export-block (export-block contents info)
>"Transcode a EXPORT-BLOCK element from Org to Markdown.
> #+end_example


--
Tim Cross



Re: How to avoid generating the Table of Contents when exporting to markdown?

2021-01-30 Thread Tim Cross


Rodrigo Morales  writes:

> When answering questions in Emacs Stack Exchange, I usually write my answer
> in Org Mode and then export it to Markdown so that I can copy it to the
> answer textbox in Stack Exchange. For this reason, I don't need the
> export to contain a Table of Contents because the Markdown content is
> not big enough to require it.
>
> For this reason, I don't want the Table of Contents to be included when
> exporting.

You can try putting

#+OPTIONS: toc:nil

in the header of your org file. This is covered in the 'Table of
Contents' sub-section of the Exporting section of the org manual.


--
Tim Cross



  1   2   3   4   >