Re: Odd characters in the fast tags selection interface
Ihor Radchenko writes:
> Hanno writes:
>
- after "a..z" runs out, '{', '|' and '}' are being used which seems
reasonable -- but after that, I get '\200' and similar before reaching
'©'...
>>>
>>>This is indeed true, but what can we do? There are only that many
>>>characters in the keyboard. We may instead start using two-key
>>>combinations for tags beyond #26, similar to org-capture. Patches are
>>>welcome!
>>
>> Thanks for the fast reply and fully agreed! I would indeed argue that
>> automatically generated keys
>> are not useful beyond a certain number (N=26?) as they could change with new
>> tags and thus are
>> hard to memorize. And taking in >N random choices every time is hardly "fast
>> select" anymore.
>>
>> In fact, the docstring for =org-fast-tag-selection= says that only a-z would
>> be automatically
>> assigned. That sounds reasonable to me (otherwise one can define more keys
>> via
>> =org-tag-persistent-alist=). Maybe this is a bug after all? If more than 26
>> choices are desired,
>> maybe A-Z (i.e. capital letters) could extend the list before more unusual
>> characters?
>>
>> What do you think?
>>
>> I am not at my computer right now but could try to come up with a patch
>> later.
>
> I am not sure. Omitting (random) part of the tags sounds awkward - some
> tags will be assigned keys and some not. I guess something that will
> improve the current situation would be simply not printing chars beyond
> a-z, while still listing all the tags - it will be less awkward compared
> to current situation when a key is printed but cannot be used anyway.
>
> Or we may provide "paging" approach that will re-assign a-z keys when
> user presses C-n/C-p. Though I do not like this idea too much because we
> have a more universal menu backend in works at
> https://orgmode.org/list/87zgisvuu5.fsf@localhost Adding new feature to
> tag menu does not feel like a good direction to go. If we decide to go
> this way at the end, we may, at least, also need to update
> org-fast-todo-selection along similar lines.
I prefer this second way, currently I don't know how to scroll tag
selection buffer. By using "paging" can solve the assigned keys problem.
Also used for other tags.
>
> Finally, we may simply not list tags with keys beyond "z" at all only
> indicating that there are more by showing some text at the end of the
> menu.
>
- when defining my own keys, they are not displayed in the top; instead
their characters are missing in the 'a'..'z' range leaving more room
for odd and very difficult-to-type characters
>>>I think that it would make sense to have `org-tag-persistent-alist`
>>>staff being shown on top. Unless there are objections I can merge this
>>>trivial change.
>>
>> Thanks, that already improves the usability a lot!
>
> Done on main via a0b21e3f1.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a0b21e3f1c131bc6ee6398e2d3dda20944d6b358
--
[ 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
signature.asc
Description: PGP signature
Re: [BUG] Inconsistent behaviour of TODO + COMMENT + TODO dependencies + agenda? [9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)]
>> P.D: Just when I was going to send this I tried to investigate it a >> little bit more to not waste anyone's time, and I found the variable >> 'org-agenda-skip-comment-trees', which defaults to 't'. So now I see that >> if it is set to 'nil' it would not be inconsistent to me anymore, but I >> still think that the default behaviour is inconsistent, or at least >> unintituive for newcomers, and that maybe a corresponding variable like >> 'org-dependencies-skip-comment-trees' might be needed. > > This makes sense. The new variable should default to the old behaviour - > we do not want to break existing Org files relying on it. > > Patches are welcome! I was going to write one, but I have found further inconsistencies and incomplete documentation and I think we should clearly define first how we want dependencies to behave. According to the Org Mode documentation and the docstrings of `org-enforce-todo-dependencies' and `org-block-todo-from-children-or-siblings-or-parent', tasks are blocked when: 1. The task has undone children tasks. 2. A task has a parent with the property :ORDERED:, and there are undone sibling tasks prior to the current task 3. The parent of the task is blocked because it has siblings that should be done first, or is child of a blocked grandparent TODO entry." But they are actually blocked when: 1. The task has undone DESCENDANT tasks (i.e., undone children of children also block) 2. A task has a parent with the property :ORDERED:, and there are sibling tasks prior to the current task which are undone OR HAVE UNDONE DESCENDANTS 3. The parent of the task is blocked because it has siblings that should be done first, or is child of a blocked grandparent TODO entry. BUT THE TASK IS NOT BLOCKED E.G., IF ITS GRANDPARENT IS BLOCKED AND IS PARENT IS DONE OR HAS NO TODO STATE. So my other issues are: - Remarks in upper case in points 1 and 2 should be clarified in the documentation and docstrings, if that is actually the desired behaviour and not a bug. Otherwise, they should be fixed. I can do that in the same patch. - I also find inconsistent that in points 1 and 2 not only parents and children are considered for blocking but also further ancestors and descendants, but in point three only a direct chain of blocked parents is considered. What do you think about them? I'll start writing the original patch for now, let me know if you want me to address any of those points too while I'm at it. Ignacio
Re: org-verse-num: display verse numbers within a verse block
> Ihor Radchenko writes: > Colin Baxter writes: >> > https://gitlab.com/maciaschain/org-verse-num >> >> Your site tells me to turn JavaScript, enable Cookies and >> complete a CAPTCHA, all of which I refuse to do. >> >> Do you have an alternative web-site? > While I understand your frustration, please note that you really > do not need to open GitLab/GitHub links in browser. All you need > to do is > git clone https://gitlab.com/maciaschain/org-verse-num Thank you. I had tried that git clone url, or at least I thought I had: my attempt came back unknown. I can only assume I entered a incorrect URL. I have now successfully cloned the repository, and it looks like something I will use. Thanks again. Best wishes,
Re: org-latex preview on Windows
Hi Jeremie In my emacs it works great. Even org-fragtog that allows you to edit in an interactive manner. - Just in case it could be helpfult, these are the lines in my init file that I can find related to LaTeX: (custom-set-variables '(org-preview-latex-image-directory "~/borrar/ltximg/") '(preview-TeX-style-dir "~/.emacs.d/elpa/auctex-13.0.11/latex" t)) - I installed LaTeX following these instructions: https://ikaruga2.wordpress.com/2011/06/14/latex-emacs-and-orgmode-in-windows/ - I have edited the Windows System Variable "Path" and added to it: C:\Program Files\MiKTeX\miktex\bin\x64\ I hope that helps El 07/08/2022 a las 18:00, emacs-orgmode-requ...@gnu.org escribió: Date: Sat, 06 Aug 2022 18:11:46 +0200 From: Jeremie Juste To:emacs-orgmode@gnu.org Subject: org-latex preview on Windows Message-ID:<87h72pwdvh@gmail.com> Content-Type: text/plain Hello everyone, I have had difficulties using org-latex-preview to run properly on Windows. The main issue seems to be that the user name on windows gets abbreviated with ~. As far as I understand this generate problems as the temporary folder cannot be found. see for instance these posts https://emacs.stackexchange.com/a/70119 and an old post from Vincente Vera https://list.orgmode.org/CAMfbzvDPLS1eqXJ=7tzh1035z3vq4q4-yjmqsvbcgxzp8kd...@mail.gmail.com/ Vincente, suggests altering the temporary environment variable (setenv "TEMP" "C:\Temp"). I have tried this option and place it in my .init file but the Temporary file in org-mode uses does not change. As a work around I modified the function org-compile-file in lisp/org/ org-macs.el by adding altering the source variable as such (let* ((source (replace-regexp-in-string "JEREMI~1" "JeremieJuste" source)) This is obviously not an ideal solution but I cannot find any other solution immediately. Have someone else come across the same issue on Windows? Do you have any suggestions? Best regards, Jeremie Org mode version 9.5.4 GNU Emacs 28.1
Re: org-verse-num: display verse numbers within a verse block
Juan Manuel Macías writes: > BTW, is there any proprietary JavaScript free alternative to > GitLab/GitHub? I would be very grateful for any recommendations. For self-hosted solutions, you may check out https://gitea.io/en-us/ -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: org-verse-num: display verse numbers within a verse block
Hello Juan, On Sunday, 7 Aug 2022 at 14:22, Juan Manuel Macías wrote: > I've added some minor improvements to my little package 'org-verse-num', > which was born out of necessity in my translation to spanish > (work-in-progress) of Homer's Odyssey (11600 verses spread over 24 > books): > https://gitlab.com/maciaschain/org-verse-num Many thanks for sharing. > > Sorry for the inconvenience. I plan to set up my own GitLab instance in > the future, but I don't have time to do it anytime soon. > > BTW, is there any proprietary JavaScript free alternative to > GitLab/GitHub? I would be very grateful for any recommendations. https://sourcehut.org/ seems to gain popularity, but they charge a fee. But it might still be less expensive than hosting your own gitlab repository. (I have no affiliation with sourcehut and I am not an expert). > > (I noticed that my previous message was sent to the duplicate list. > Apologies for that). No problem for posting to two lists. I didn't know about emacs-humanities . Best regards, Jeremie
Re: org-verse-num: display verse numbers within a verse block
Colin Baxter writes: > Your site tells me to turn JavaScript, enable Cookies and complete a > CAPTCHA, all of which I refuse to do. > > Do you have an alternative web-site? Sorry for the inconvenience. I plan to set up my own GitLab instance in the future, but I don't have time to do it anytime soon. BTW, is there any proprietary JavaScript free alternative to GitLab/GitHub? I would be very grateful for any recommendations. (I noticed that my previous message was sent to the duplicate list. Apologies for that). Best regards, Juan Manuel -- -- -- Juan Manuel Macías https://juanmanuelmacias.com https://lunotipia.juanmanuelmacias.com https://gnutas.juanmanuelmacias.com
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
alain.coch...@unistra.fr writes:
> alain.coch...@unistra.fr writes on Sat 9 Jul 2022 08:10:
>
> > the examples I found on this mailing list did not work for me).
>
> I think I now understand why this was so: because latexmk was not
> installed on my system. In this case the docstring of
> org-latex-pdf-process says that
>
>Its value is ("%latex -interaction nonstopmode -output-directory %o
>%f" "%latex -interaction nonstopmode -output-directory %o %f"
>"%latex -interaction nonstopmode -output-directory %o %f")
>
> (which does not include bibtex, hence the problem I had) while, if
> latexmk is installed,
Can we improve the default value to have a BibTeX call?
Also, we may add a section describing recommended software to be
installed for LaTeX export (like latexmk).
WDYT?
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
Re: org-verse-num: display verse numbers within a verse block
Colin Baxter writes: > > https://gitlab.com/maciaschain/org-verse-num > > Your site tells me to turn JavaScript, enable Cookies and complete a > CAPTCHA, all of which I refuse to do. > > Do you have an alternative web-site? While I understand your frustration, please note that you really do not need to open GitLab/GitHub links in browser. All you need to do is git clone https://gitlab.com/maciaschain/org-verse-num And then open README.org in Emacs. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: org-verse-num: display verse numbers within a verse block
> Juan Manuel Macías writes: > Hi all, I've added some minor improvements to my little package > 'org-verse-num', which was born out of necessity in my translation > to spanish (work-in-progress) of Homer's Odyssey (11600 verses > spread over 24 books): > https://gitlab.com/maciaschain/org-verse-num Your site tells me to turn JavaScript, enable Cookies and complete a CAPTCHA, all of which I refuse to do. Do you have an alternative web-site?
org-verse-num: display verse numbers within a verse block
Hi all, I've added some minor improvements to my little package 'org-verse-num', which was born out of necessity in my translation to spanish (work-in-progress) of Homer's Odyssey (11600 verses spread over 24 books): https://gitlab.com/maciaschain/org-verse-num org-verse-num includes some functions and a minor mode to aid in navigating through (very) long poems within an Org-mode verse block. It displays verse numbers sequentially (avoiding empty lines between stanzas) and you can also move the cursor to a specific verse number. Best regards, Juan Manuel -- -- -- Juan Manuel Macías https://juanmanuelmacias.com https://lunotipia.juanmanuelmacias.com https://gnutas.juanmanuelmacias.com
Re: Suggestion with footnotes when toggling headlines into plain lists
Ypo writes: > When turning headlines into plain lists ~(org-ctrl-c-minus)~, I think > footnotes should be moved to the bottom of the main headline. > > Example; Original headlines: > > * Main headline > ** Headline 1 > [fn:1] > > [fn:1] > * Headline 2 > > > ~C-c -~ turns that into a list where footnotes definitions can't be > found. It gives, for example, problems when exporting or when more > footnotes are added: > > * Main headline > - Headline 1 > [fn:1] > > [fn:1] > - Headline 2 Confirmed. Transforming footnote-definition into footnote-reference is not intended and should be considered a bug. > The desired outcome, could be something like this: > > * Main headline > - Headline 1 > [fn:1] > - Headline 2 > [fn:1] This will make sense. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: how obtain automatic row numbers in a table starting after the second hline?
Hi, Uwe,
Three ideas:
1. Since your solution depends on the row number (@#) in any case, your
use case does not actually depend on hline-relative references, does
it? Then you can also assign to absolute row numbers, either by
- assigning to the range rather than to the colum, which is not
possible with hline relative references (the obvious
@II$1..@>$1=@#-1+572 is not allowed), but with an absolute start
reference it works:
| Nr |
|-|
| |
|-|
| 574 |
| 575 |
| 576 |
| 577 |
#+TBLFM: @3$1..@>$1=@#-1+572
- or assigning to the row first, then assigning the content between
the hlines to that cell (perhaps a fragile solution).
| Nr |
|-|
| |
|-|
| 574 |
| 575 |
| 576 |
| 577 |
#+TBLFM: $1=@#-1+572::@2$1=string("")
2. Use a conditional to avoid changing the cell between the hlines, e.g.:
| Nr |
|-|
| foo |
|-|
| 574 |
| 575 |
| 576 |
| 577 |
#+TBLFM: $1=if(@# < 3, @0$1, @#+571)
Here, I use @0$1 to replace that cell with itself. If the cell is empty,
this evaluates as 0, so if you want an empty string, use string("")
instead of @0$1.
3. Add a first column with special marking characters (see Org manual:
Spreadsheet: Advanced features), leaving empty the cell between the
hlines so it won't get recalculated.
| | Nr |
|---+-|
| | |
|---+-|
| * | 574 |
| * | 575 |
| * | 576 |
| * | 577 |
#+TBLFM: $2=@#-1+572
Yours,
Christian
Uwe Brauer writes:
> Hi
>
> I would like to obtain
> #+begin_src
>
> | Nr |
> |-|
> | |
> |-|
> | 574 |
> | 575 |
> | .. |
> | 680 |
> #+end_src
>
> I tried
> #+begin_src
>
> | Nr |
> ||
> | 1 |
> ||
> | 1 |
> | 2 |
> #+TBLFM: $1=vlen(@II$1..0);EN
> #+end_src
>
> or
> #+begin_src
>
> | Nr |
> |-|
> | 573 |
> |-|
> | 574 |
> | 575 |
> #+TBLFM: $1=@#-1+572
> #+end_src
>
> None worked, any ideas?
>
> thanks
>
> Uwe Brauer
Re: Bug: Folding problem with markdown source block
Jack Kamm writes: > I found that Org entries containing markdown source blocks don't get > properly folded on the main development branch, when markdown-mode is > also loaded. > > To reproduce: > > 1. Download markdown-mode from MELPA or Github. [1] > 2. Fix the paths in the attached init.el. > 3. emacs -Q -l init.el test.org > 4. Shift-tab to collapse the visibility Thanks for reporting! Fixed on main via 00adad935. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=00adad9357b9123a7b11ecf12c148a5196debcb7 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [RFC PATCH] oc-csl: Add support for title, locators and bibentry styles
András Simonyi writes: > the attached patch adds support for three new citation styles which > recently got supported by citeproc-el: > > - cite/title or cite/ti to cite only the title of an item, > - cite/locators or cite/l to cite only the locators, and > - cite/bibentry or cite/b to cite the full bibliography entry. LGTM in general, but please add a proper commit message. See https://orgmode.org/worg/org-contribute.html#commit-messages Also, it would be useful to explain a bit what bibentry stands for. Maybe provide an example. > I put "RFC" in the subject because I'm not entirely sure about naming > the "bibentry" style, since "bibentry" is natbib terminology, I think, > and biblatex's corresponding command is \fullcite, but I find > "bibentry" slightly more adequate. Also, do we need the "ti" > abbreviation for the "title" style? I guess Bruce has answered all the questions. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] Re: the comment environment does not work for checkboxes
Ihor Radchenko writes: > Thanks for the heads-up! > Comment blocks are not supposed to contain Org markup, and thus it indeed > makes sense to support them in org-edit-special and in structure > templates. > > See the attached patch. Applied onto main via a303a794f. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a303a794f8c6f880aa8dc46f10179890bfd27423 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [BUG] Error when editing properties in column view [9.5.3 (release_9.5.3-452-g407104 @ /home/mbork/others-works/emacs/org-mode/lisp/)]
Ihor Radchenko writes: > Marcin Borkowski writes: > >> When I try to edit a property in column view, I get the following error >> message: >> >> Invalid column specification format: nil >> >> This only seems to happen if the point is not too close to the left >> margin. I did a bit of digging and found out that the culprit is most >> probably the `org-columns-update' function, which contains this: > > Thanks for the report! > Confirmed. Fixed. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Bug: Folding problem with markdown source block
Hello Jack, Thanks for reporting. I can reproduce the bug. Best regards, Jeremie On Saturday, 6 Aug 2022 at 14:10, Jack Kamm wrote: > Hello, > > I found that Org entries containing markdown source blocks don't get > properly folded on the main development branch, when markdown-mode is > also loaded. > > To reproduce: > > 1. Download markdown-mode from MELPA or Github. [1] > 2. Fix the paths in the attached init.el. > 3. emacs -Q -l init.el test.org > 4. Shift-tab to collapse the visibility > > Output should look like this: > > * Headline 1... > > But instead I observe this: > > * Headline 1... ``` > ... ``` > ... > > If markdown-mode isn't loaded, then the problem goes away. I think the > problem might have to do with the fontification that markdown-mode > applies to the back-quoted code block. > > Versions: > GNU Emacs 28.1 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version > 1.17.6, Xaw3d scroll bars) of 2022-07-10 > Org mode version 9.5.4 (release_9.5.4-717-g9cc60d @ > /home/jack/dev/org-mode/lisp/) > > [1] https://github.com/jrblevin/markdown-mode > > > (add-to-list 'load-path "~/.emacs.d/elpa/markdown-mode-20220708.6") > (require 'markdown-mode) > > (add-to-list 'load-path "~/dev/org-mode/lisp") > > > * Headline 1 > ** Headline 1a > > #+begin_src markdown > Some source code: > > ``` > echo hello world > ``` > > A list: > > ,* Item 1 > ,* Item 2 > #+end_src > > ** Headline 1b > > Lorem ipsum.
