Re: id links in non-org buffers

[Robert Weiner]

The current pre-release package of Hyperbole from the elpa-devel archive
will display any Org ID (typically a UUID) or Org Roam ID referent given an
ID in any buffer.  Simply press M-RET on the ID with Hyperbole active and
the referent/definition is displayed in another window or frame (whatever
Hyperbole display setting you have).  Clean and simple.  Give it a try.

-- rsw


On Fri, Jun 23, 2023 at 1:02 PM Ihor Radchenko  wrote:

> Samuel Wales  writes:
>
> > will any package highlight or follow org id in non-org?
>
> How would IDs look like in non-org?
>
>

Re: [BUG] org-babel-tangle: Header arg `:comments org' produces no comment in the output [9.7-pre (release_9.6.6-418-g294a4d @ /home/nick/src/emacs/org/org-mode/lisp/)]

[Nick Dokos]

Ihor Radchenko  writes:

> Nick Dokos  writes:
>
>> A couple of nits: maybe the comment that `org-back-to-heading' sets match
>> data should be deleted?  And there is a typo in the initial comment of
>> the test you added (thanks for adding it!): `:commends org' should be
>> `:comments org'.
>
> Thanks!
> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f56ca5009
>
>> Also, I found a couple of places in the code where `org-back-to-heading' is 
>> called
>> and then match data are used. I don't know if there is a problem or not, but 
>> it might
>> be worth double checking to make sure that the usage makes sense:
>>
>> - org.el: l.20792 in `org-forward-heading-same-level'
>> - org-mouse.el: l.976 in `org-mouse-transform-to-outline'
>
> Right.
> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=57bb9cada
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0a842cc94

Thank you!

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

[ANN] EmacsConf 2023 Call for Participation

[Amin Bandali]

Dear fellow Emacsians,

We are excitedly calling for your participation for EmacsConf 2023,
planned for December 2 and 3, 2023 (Sat-Sun)!  Please submit your
proposal(s) by September 14, 2023 (Friday).  See below for details on
how to send in your proposals, or chat with us about them and about
other ways of participating and volunteering around EmacsConf via our
main IRC channel #emacsconf on the Libera.Chat network.

As an entirely volunteer-run conference we are always looking for more
volunteers and organizers to help with various aspects of organizing
and running the conference, including reviewing session proposals and
streaming parallel tracks.  To get involved, please come by our IRC
channel or one of our public mailing lists (see below) and introduce
yourself and tell us about your interests, or contact myself or one of
the other organizers directly if you're feeling a bit shy; we hope to
hear from you. :-)

Best,
amin

P.S. please direct any replies for this message either to me or to the
emacsconf-discuss list, so as to help avoid generating extra off-topic
chatter in the other lists Cc'd on this message.  Thank you.


  ___

 EmacsConf 2023
   Online Conference
  ___


 December 2 and 3, 2023


Table of Contents
_

1. Call for participation
2. Talk formats
3. Submitting your proposal
4. Know someone who might have something to share?
5. Want to volunteer?
6. Commitment to freedom


1 Call for participation


  What have you found exciting about [Emacs] lately?  Have you figured
  out a good workflow?  Used Emacs for something interesting?  Come
  share what you've been learning at EmacsConf 2023 and meet other
  enthusiasts along the way!  All backgrounds and all levels of
  experience are welcome.  Emacs isn't just a text editor, it's a way
  of life!

  Not sure what to talk about?  We've shared a few [ideas] to help you
  get started.

  [EmacsConf 2023] will be a virtual conference on *December 2 and 3,
  2023 (Sat-Sun, 9AM-5PM UTC-5 / 2PM-10PM UTC)*.  If you'd like to
  present at the conference, please *[submit your proposal]* by
  *September 14, 2023 (Friday)*.


[Emacs] 
[ideas] 
[EmacsConf 2023] 
[submit your proposal] 


2 Talk formats
==

  Ideally, talks will be prerecorded so that you can script and edit
  them as tightly as you want, and so that they can be captioned for
  accessibility.  Here are the talk options:

  - *5-10 minute lightning talk:* just the essentials!  If you can
squeeze your prerecorded talk into 5-10 minutes by focusing on
the essentials (not by talking super quickly!), we might be able
to repeat it during the conference in order to fill gaps.
  - *20-minute talk:* short enough to keep people's attention, long
enough to get into some details.

  There will be time for questions and answers after your talk, so
  you don't need to include that in your talk timing.  Just like in
  EmacsConf 2022, you can answer questions via a BigBlueButton room,
  IRC, the Etherpad, the wiki, or email (your choice).  The stream
  will move on to the next talk at the scheduled time, but interested
  people can keep hanging out with you for a longer conversation.

  If you are not available during the conference itself but you have
  a neat idea that you'd like to share, please propose it anyway!
  You can always handle questions after the conference, and we might
  even be able to coordinate with other Emacs meetups for events in
  other timezones.

  We may have time for a few longer sessions.  If you'd like to be
  considered for a longer time slot, please include an outline for the
  extra time in addition to your 20-minute proposal.  Other session
  formats such as tutorials, workshops, and hangouts are welcome as
  well.


3 Submitting your proposal
==

  [Send us your idea] as soon as you can, so that you can have more
  time to work on your talk.  (Proposal deadline: September 14, 2023)
  This year, we'd like to experiment with accepting proposals
  throughout the CFP process.  If there are similar proposals, we'll
  work with people so that the talks can cover different facets.

  If you need help, you can email us publicly at
  [emacsconf-...@gnu.org] or privately at
  [emacsconf-org-priv...@gnu.org]. You can also come and say hi
  to us on our IRC channel `#emacsconf' on `irc.libera.chat' using
  [your favourite IRC client], or by visiting [chat.emacsconf.org] in
  your web browser.


[Send us your idea] 
[emacsconf-...@gnu.org] 
[emacsconf-org-priv...@gnu.org] 
[your favourite IRC client] 
[c

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Ihor Radchenko]

Sébastien Miquel  writes:

> Ihor Radchenko writes:
>> May you please provide an example for such breakage?
>>  From my point of view, alignment is far lesser concern compared to
>> indentation breaking code execution/tangling/other functional parts of Org.
>
> Let's say tab-width is 8 and elisp-mode uses tabs for indentation. In
> the following snippet, arg2 should be indented with a tab.
>
> #+BEGIN_SRC emacs-lisp
> (some-f arg1
>  arg2) ;; arg2 is indented at column 8
> #+END_SRC
>
> If I add two spaces at the beginning of the block. It should visually
> look like this:
>
> #+BEGIN_SRC emacs-lisp
>(some-f arg1
>  arg2) ;; arg2 is indented at column 8
> #+END_SRC

This is not a problem. We can just apply appropriate 'display property
in `org-src-font-lock-fontify-block', manually replacing the tab with
appropriate number of spaces (as in the origin buffer).

> Calling =indent-to= would rather put the two spaces after the tab
> character.

Then, we should not use `indent-to' and instead put spaces manually.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Sébastien Miquel]

Ihor Radchenko writes:

May you please provide an example for such breakage?
 From my point of view, alignment is far lesser concern compared to
indentation breaking code execution/tangling/other functional parts of Org.


Let's say tab-width is 8 and elisp-mode uses tabs for indentation. In
the following snippet, arg2 should be indented with a tab.

#+BEGIN_SRC emacs-lisp
(some-f arg1
arg2) ;; arg2 is indented at column 8
#+END_SRC

If I add two spaces at the beginning of the block. It should visually
look like this:

#+BEGIN_SRC emacs-lisp
  (some-f arg1
arg2) ;; arg2 is indented at column 8
#+END_SRC

Calling =indent-to= would rather put the two spaces after the tab
character. But then we lose this idea of clean separation between the
org indentation and the native indentation, and we will need to
convert the indent of every line on subsequent edits (org -> elisp),
as well as for tangling, or code execution. If we have to do this, we
might as well just respect the org buffer =indent-tabs-mode=, and redo
every indentation with each conversion. This could possibly be costly
when tangling a large buffer.

The visual breakage would be much more common than those more serious
issues, which had gone unnoticed so far.

--
Sébastien Miquel

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Ihor Radchenko]

Sébastien Miquel  writes:

> On second thought, I don't think that's a good idea. I did not
> understand how tab characters worked: they do not have a fixed width,
> but align to the next tab column. This means that if we add a couple
> of spaces in front of a tab indented piece of code, we can break
> vertical alignment in the org buffer, which I think is pretty bad.

May you please provide an example for such breakage?
>From my point of view, alignment is far lesser concern compared to
indentation breaking code execution/tangling/other functional parts of Org.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Sébastien Miquel]

Sébastien Miquel writes:

Should we use native buffer's value of =indent-tabs-mode= to set
=use-tabs?= ? I think this trivial change should work.


It doesn't seem quite that easy. If we want to add 4 columns to a tab
indented line (and tab width is 8), we can either call =indent-to= to
indent with a tab and 4 spaces, or add the spaces at the beginning.
With the second option, we risk breaking vertical alignement in the
org buffer. With the first option, on a subsequent edit, the current
=org-do-remove-indentation= will break the tab character into 4
spaces, making the indentation 8 spaces instead of a tab. You need to
have =org-do-remove-indentation= re-indent the whole line, with the
correct value of =indent-tabs-mode=.

--
Sébastien Miquel

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Sébastien Miquel]

Hi Ihor,

Ihor Radchenko writes:

...But I guess
what you propose amounts to
...

You are right.


On second thought, I don't think that's a good idea. I did not
understand how tab characters worked: they do not have a fixed width,
but align to the next tab column. This means that if we add a couple
of spaces in front of a tab indented piece of code, we can break
vertical alignment in the org buffer, which I think is pretty bad.

Should we use native buffer's value of =indent-tabs-mode= to set
=use-tabs?= ? I think this trivial change should work.

--
Sébastien Miquel

Re: How to install org-protocol

[Max Nikulin]

On 25/06/2023 17:40, Ypo wrote:

then I was stuck with Windows.


Do you have any suggestions concerning the configuration recipe on Worg?

Next thing I would like to do is to capture fragments of websites, and 
to save them automatically with this format:

* Author. Data. /Title/. Website.
Link
Captured text


LinkRemark could not do it out of the box. Title format variants are 
currently hardcoded. E.g. product description handled in a special way. 
Result depends on available metadata and on length of particular fields. 
You may however experiment with "object" export format that gives a JSON 
object. Depending on your favorite programming language, custom 
formatting may be implemented in a native messaging backend or by 
calling a function in a capture template.

https://github.com/maxnikulin/linkremark/issues/1

Re: Reintroduction and Questions

[Ihor Radchenko]

Matt  writes:

> To verify my understanding, the mailing list is the "source of truth" for 
> issues and Woof! "scrapes" that?

Yes, you are correct.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at