Re: [O] Problem with J Source Code Blocks in Org Mode

[Bill Harris]

Nicolas,

Thanks for the idea.  It turns out I also got a suggestion on the J General
list, and that one worked.  See
http://jsoftware.com/pipermail/general/2017-December/037375.html.

Bill

Re: [O] Poll: new keybinding for org-insert-structure-template?

[Eric Abrahamsen]

Rasmus  writes:

> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> Rasmus  writes:
>>
>>> Nicolas, are there any public interfaces to make ox export like
>>> interfaces?
>>
>> No, there isn't. However, Org provides `org-mks'.
>
> Good point.  It isn’t quite as nice as the export dispatcher.  Let’s wait
> and see what Eric prefers.

I don't have to own this! I don't have a strong feeling about it, and
left to my own devices would just keep the single-character keys. But I
see why people would want more/longer keys, and better discoverability.

The main desires are:

1. String keys of arbitrary length.
2. Discoverability: either a window of choices pops up automatically, or
   you can do it with TAB, etc.
3. Ideally, you don't have to hit an extra key to finish.

Given that, it seems to me that `org-mks' is just fine. It doesn't do as
much as the export dispatcher, but I don't see that it needs to.

The only downside is that it might make the choices a bit harder to
customize, as the table argument is more fiddly. But maybe not a big
deal.

Eric

Re: [O] Key binding popup interface

[Robert Weiner]

On Tue, Dec 12, 2017 at 4:01 PM, Stefan Monnier 
wrote:

>
> > Can hydra.el be merged into Emacs core, so that all the packages can
> start
> > taking advantage of that?
>
> I have no opinion on that part, but if a part of Hydra would be useful
> for other packages, then it'd be good to split it out: for me "Hydra"
> means "define a Hydra via defhydra or something like that", so if you
> tell me to use Hydra to "show the available valid key bindings",
> I wouldn't know where to start.
>

​One limitation of hydra right now is that it doesn't interface with the
standard way of showing help for key bindings since its keys aren't
actually bound but handled via internal hydra event handling.  With a bit
of thought though, I think it could be integrated well.

Bob
​

Re: [O] Key binding popup interface

[Stefan Monnier]

>> While Hydra might include the feature you're looking for, AFAICT it does
>> something else than what you're looking for.
> I don't follow "it does something else than what you're looking for". hydra
> is used to define interfaces to temporary keymaps with well-formatted hints.

I tend to think of Hydra as "bindings that stick around" (to take the
wording on the first line of hydra.el), rather than "ways to show
available bindings of the current submap".  So, yes, I think it does
something else (something more) than what I understand you want.

And, BTW, if I take a hydra like

(defhydra hydra-zoom (global-map "")
  "zoom"
   ("g" text-scale-increase "in")
   ("l" text-scale-decrease "out"))

and I press `f6` I don't get any help in the echo area (nor in the "lv"
area).  I only get that help after pressing `f6 g` or `f6 l`, so I need
some other mechanism to find those "initial" key bindings.

So in this respect, I think it does something less than what
I understand you'd want.

> I quickly went though hydra.el.. isn't defhydra mainly what it is? What
> would you suggest splitting out of that library?

I don't know enough about it to have a clear opinion on that.


Stefan

Re: [O] Key binding popup interface

[Kaushal Modi]

On Tue, Dec 12, 2017 at 4:05 PM Stefan Monnier 
wrote:

> > Problem statement: Need to have a pretty interface that shows the
> available
> > valid key bindings.
> [...]
> > Of all those options and more that I've seen out there, hydra.el looks
> like
> > the most elegant and *configurable* option.
>
> While Hydra might include the feature you're looking for, AFAICT it does
> something else than what you're looking for.
>

I don't follow "it does something else than what you're looking for". hydra
is used to define interfaces to temporary keymaps with well-formatted hints.

I have no opinion on that part, but if a part of Hydra would be useful
> for other packages, then it'd be good to split it out: for me "Hydra"
> means "define a Hydra via defhydra or something like that", so if you
> tell me to use Hydra to "show the available valid key bindings",
> I wouldn't know where to start.
>

I meant that use hydra to define such interfaces.. the package authors
would need to use hydra to define these interfaces. All the user would need
to know is to hit some X binding to get that popup interface.

I quickly went though hydra.el.. isn't defhydra mainly what it is? What
would you suggest splitting out of that library?
-- 

Kaushal Modi

Re: [O] Key binding popup interface

[Stefan Monnier]

> Problem statement: Need to have a pretty interface that shows the available
> valid key bindings.
[...]
> Of all those options and more that I've seen out there, hydra.el looks like
> the most elegant and *configurable* option.

While Hydra might include the feature you're looking for, AFAICT it does
something else than what you're looking for.

> Can hydra.el be merged into Emacs core, so that all the packages can start
> taking advantage of that?

I have no opinion on that part, but if a part of Hydra would be useful
for other packages, then it'd be good to split it out: for me "Hydra"
means "define a Hydra via defhydra or something like that", so if you
tell me to use Hydra to "show the available valid key bindings",
I wouldn't know where to start.


Stefan

Re: [O] Key binding popup interface

[Kaushal Modi]

On Tue, Dec 12, 2017 at 3:47 PM Eric Abrahamsen 
wrote:

>
> Okay, interesting. I agree that "discoverable keymaps" and "action
> dispatchers" (whatever Org and Magit do) aren't quite the same thing,
> and it would be nice to have both. I guess in the meantime, though,
> we're still going to have to use something else for the Org structure
> thing.
>

Correct. That's why I spawned off this "something for future" thread, and
did not talk about this in the original thread[1] :)

[1]: http://lists.gnu.org/r/emacs-orgmode/2017-12/msg00221.html
-- 

Kaushal Modi

Re: [O] Broken org-mode "Column width and alignment" in latest version

[Kaushal Modi]

On Sat, Dec 9, 2017 at 1:11 PM Ruy Exel  wrote:

> Dear Kaushal,
>
> The real treat is to read your nice message and to be a member of such a
> fantastic group of people!
>
> Following your advice to stick to a stable release I searched for info on
> how to install it and I found instructions in
> http://orgmode.org/org.html#Installation telling me to run "M-x
> package-install RET org RET" from within emacs.  I did it and it all looked
> like everything was running smoothly untill I was issued the messages:
>
> WARNING: No org-loaddefs.el file could be found from where org.el is
> loaded.  You need to run "make" or "make autoloads" from Org lisp directory
>

Did you add Org Elpa to package archives as described here:
http://orgmode.org/elpa.html ?

I am used to this since I first tried the cloned git version, but I noticed
> that there is no Makefile in the directory containing the newly dowloaded
> files (~/.emacs.d/elpa/org-20171113/), so I got stuck.
>

I haven't installed Org from within Emacs for quite some time now as I
build it using make from its git clone. Also I haven't seen the warning
that you see. Hopefully someone else can comment on that part.

I noticed though that the Org version you quoted:
~/.emacs.d/elpa/org-20171113/ is a bit old (not too old, but not the latest
served on Elpa either). If you add the Org Elpa to package-archive as I
suggested above, and install using the M-x package-list-packages interface,
the archives will first get auto-refreshed, and then you can be rest
assured that the installed packages are the latest versions.


> I noticed that in the above installation instructions it is mentioned that:
>
> Important: you need to do this in a session where no .org file has been
> visited, i.e., where no Org built-in function have been loaded. Otherwise
> autoload Org functions will mess up the installation.
>
> so I repeated the process right after starting emacs with the
> --no-init-files option, then I added the line "(package-initialize)" to my
> initialization file but it still does not work,
>

What doesn't work? You shouldn't need to do --no-init-files. Simply make
sure that your config is not doing (require 'org) directly or indirectly
somewhere and you are not opening an Org file at emacs startup. That's all.


> namely the old org-mode is loaded upon starting emacs.
>

How are you telling that? If you do M-: (featurep 'org) and it returns nil,
it means that org is not yet loaded.


>   It is curious that I now have two org-mode entries in the top Emacs-Info
> node, one for the old version (7.9.3f) and another one for the new one
> (9.1.2 (release_9.1.2-37-g3f8d67)).
>

That's a different thing, has to do with the Info-directory-list variable,
and is fine. You can have paths to Info manuals from multiple Org versions
added to that var, and so you will see multiple Org manuals. I personally
don't like that and so I surgically remove[1] all the Org versions that I
am not using in the current emacs session from load-path and
Info-directory-list.

Could I have premanently messed up my emacs installation by not following
> the above Important advice?
>

Not trying to sound philosophical, but nothing is permanent. All the
package installations happen in the elpa dir.. so to start the Org
installation from scratch, you can rm -rf all the org installations from
the elpa/ dir and restart emacs following that "Important" instruction and
retry installing Org.

[1]: https://scripter.co/building-org-development-version/
-- 

Kaushal Modi

Re: [O] Key binding popup interface

[Kaushal Modi]

On Tue, Dec 12, 2017 at 3:20 PM Eric Abrahamsen 
wrote:

>
> Hydra definitely sounds nice, but unless I'm misunderstanding how it
> works, it can't be a replacement for either Org's export interface, or
> Magit's popups. Both of those can set various state variables before
> choosing an actual action -- Hydra can't do that, can it?
>

hydra can do anything you can do in elisp before/after the action.

For example, here's a hydra I use for rectangle actions:

(defhydra hydra-rectangle (:body-pre (rectangle-mark-mode 1)
   :color pink
   :post (deactivate-mark)
   :hint nil)
  "
  Rectangle:
  ^_p_^_d_   delete  _s_tring_c_/_C_ (delete/kill) and
replace with space
_b_   _f_  _k_   cut _r_eset _o_pen (create blank
rectangle and push text in region to the right)
  ^_n_^_w_   copye_x_change  _X_ delete whitespace
starting from the left edge of the rectangle
   _y_   paste   _e_xtendPrefix rectangle lines
with _N_umbers
"
  ("b"   backward-char)
  ("f"   forward-char)
  ("p"   previous-line)
  ("n"   next-line)

  ("d"   delete-rectangle :color blue)
  ("k"   kill-rectangle :color blue)
  ("w"   copy-rectangle-as-kill :color blue)
  ("y"   yank-rectangle :color blue)
  ("s"   string-rectangle :color blue)
  ("t"   string-rectangle :color blue)
  ("r"   (if (region-active-p)
 (deactivate-mark)
   (rectangle-mark-mode 1)))
  ("x"   ora-ex-point-mark)
  ("e"   modi/extend-rectangle-to-end)
  ("c"   clear-rectangle)
  ("C"   modi/kill-rectangle-replace-with-space :color blue)
  ("o"   open-rectangle :color blue)
  ("X"   delete-whitespace-rectangle :color blue)
  ("N"   rectangle-number-lines :color blue)
  ("q"   nil "cancel" :color blue))

Note the use of :body-pre, :post in above example. More details here:
https://github.com/abo-abo/hydra/wiki/internals#body-pre


But this email wasn't to propose replace the matured popups like magit and
org export with hydra. The proposal is to integrate hydra into emacs, so
that many packages that self-implement these popups can do the same using
hydra more easily. Dired, ibuffer can make use of hydra and make all the
bindings more discoverable and memorable. In future, may be hydra can be
use for the org template insertion piece.

I can talk of verilog-mode as I use it everyday. In verilog-mode.el, there
is this code:

(defvar verilog-template-map
  (let ((map (make-sparse-keymap)))
(define-key map "a" 'verilog-sk-always)
(define-key map "b" 'verilog-sk-begin)
  ..
  (define-key map "D" 'verilog-sk-define-signal)
map)
  "Keymap used in Verilog mode for smart template operations.")

In my config, I replace the same with hydra and it looks like this:

(defhydra hydra-verilog-template (:color blue
  :hint nil)
  "
_i_nitial_?_ if _j_ fork
_A_ssign_uc_ uvm-component
_b_egin  _:_ else-if_m_odule
_I_nput _uo_ uvm-object
_a_lways _f_or  _g_enerate _O_utput
^^   _w_hile_p_rimitive_=_ inout
^^   _r_epeat   _s_pecify
_S_tate-machine _h_eader
^^   _c_ase _t_ask
_W_ire  _/_ comment
^^   case_x__F_unction _R_eg
^^   case_z_^^ _D_efine-signal
"
  ("a"   verilog-sk-always)
  ("b"   verilog-sk-begin)
  ...
  ("D"   verilog-sk-define-signal)
  ("q"   nil nil :color blue)
  ("C-g" nil nil :color blue))

Which gives in these interface which makes the bindings much more memorable
and accessible:

[image: image.png]
There are so many places like this that can get a facelift from hydra.

Did I hear that Magit was breaking its popup interface out into a
> separate library? If so, that would also be a nice thing.
>

That would be great too. We are basically missing a configurable library to
bind temporary key maps, that can make the bindings present in a
discoverable way to the user. So far hydra.el fits the bill.
-- 

Kaushal Modi

Re: [O] Key binding popup interface

[Eric Abrahamsen]

Kaushal Modi  writes:

> Copying this on both Emacs devel and Org mode list. Hopefully this discussion 
> is eligible for that. 
>
> Problem statement: Need to have a pretty interface that shows the available 
> valid key bindings. 
>
> We have something custom developed for Org export interface. Magit has its 
> own popup interface. I know verilog-mode.el has something in-house for 
> picking the skeleton for insertion, but the interface is not as good as 
> hydra's. 
> Projectile.el (not on GNU Elpa) has its projectile commander, another 
> in-house attempt to get a similar pop-up interface. 
>
> Of all those options and more that I've seen out there, hydra.el looks like 
> the most elegant and *configurable* option. 
>
> Can hydra.el be merged into Emacs core, so that all the packages can start 
> taking advantage of that? We need to stop having each package develop their 
> own way to do this same thing. 

Hydra definitely sounds nice, but unless I'm misunderstanding how it
works, it can't be a replacement for either Org's export interface, or
Magit's popups. Both of those can set various state variables before
choosing an actual action -- Hydra can't do that, can it?

Did I hear that Magit was breaking its popup interface out into a
separate library? If so, that would also be a nice thing.

Re: [O] Key binding popup interface

[Alan E. Davis]

I discovered accidentally some years ago, when I had been using a popup
help function that I cobbled together myself with a hot key, that
-F1 loads a list of bindings under that prefix.  It's an awesome
feature of GNU/Emacs.

Alan Davis

On Tue, Dec 12, 2017 at 10:56 AM, Kaushal Modi 
wrote:

> On Tue, Dec 12, 2017 at 1:48 PM Eric S Fraga  wrote:
>
>> On Tuesday, 12 Dec 2017 at 14:02, Kaushal Modi wrote:
>> > Copying this on both Emacs devel and Org mode list. Hopefully this
>> > discussion is eligible for that.
>> >
>> > Problem statement: Need to have a pretty interface that shows the
>> available
>> > valid key bindings.
>>
>> which-key-mode works well for me.
>>
>
> I use which-key too, but that serves a different purpose.
>
> which-key shows *all* bindings that begin with a prefix.
>
> hydra creates a quick keymap that can be bound to any key of user's
> choice. Then the user needs to just set that main binding, and all the
> sub-bindings in that keymap stay the same.
>
> - Hydra basics[1]
> - Projectile hydra example[2]
> - Rectangle operations[3]
>
> (See many more examples in that wiki.)
>
> Very vaguely speaking, which-key is a read-only utility, hydra is a create
> + read utility. We need the "create" portion for the org stucture template
> replacement discussed on the Org thread. I understand that while hydra
> cannot be integrated in emacs 26 and so Org cannot immediately start using
> it, it will be very much useful to many packages in future if first hydra
> is baked into the emacs core.
>
> [1]: https://github.com/abo-abo/hydra/wiki/Basics
> [2]: https://github.com/abo-abo/hydra/wiki/Projectile
> [3]: https://github.com/abo-abo/hydra/wiki/Rectangle-Operations
> --
>
> Kaushal Modi
>



-- 
[Fill in the blanks]

The use of corrupt manipulations and blatant rhetorical ploys ...---
outright lying, flagwaving, personal attacks, setting up phony
alternatives, misdirection, jargon-mongering, evading key issues, feigning
disinterested objectivity, willful misunderstanding of other points of
view---suggests that ... lacks both credibility and evidence.

  Edward Tufte (in context of making presentations)

Re: [O] Key binding popup interface

[Kaushal Modi]

On Tue, Dec 12, 2017 at 1:48 PM Eric S Fraga  wrote:

> On Tuesday, 12 Dec 2017 at 14:02, Kaushal Modi wrote:
> > Copying this on both Emacs devel and Org mode list. Hopefully this
> > discussion is eligible for that.
> >
> > Problem statement: Need to have a pretty interface that shows the
> available
> > valid key bindings.
>
> which-key-mode works well for me.
>

I use which-key too, but that serves a different purpose.

which-key shows *all* bindings that begin with a prefix.

hydra creates a quick keymap that can be bound to any key of user's choice.
Then the user needs to just set that main binding, and all the sub-bindings
in that keymap stay the same.

- Hydra basics[1]
- Projectile hydra example[2]
- Rectangle operations[3]

(See many more examples in that wiki.)

Very vaguely speaking, which-key is a read-only utility, hydra is a create
+ read utility. We need the "create" portion for the org stucture template
replacement discussed on the Org thread. I understand that while hydra
cannot be integrated in emacs 26 and so Org cannot immediately start using
it, it will be very much useful to many packages in future if first hydra
is baked into the emacs core.

[1]: https://github.com/abo-abo/hydra/wiki/Basics
[2]: https://github.com/abo-abo/hydra/wiki/Projectile
[3]: https://github.com/abo-abo/hydra/wiki/Rectangle-Operations
-- 

Kaushal Modi

Re: [O] Lists with bullets and checkboxes in beamer

[Eric S Fraga]

On Tuesday, 12 Dec 2017 at 17:24, Ken Mankoff wrote:
> Hi List,
>
> I have some lists with checkboxes like this:
>
> + [X] Foo
> + [ ] Bar
>
>
> When I export these to Beamer, I get both a bullet and a [] box. The
> bullet is redundant and adds noise to the slide. Is there a way to not
> have the bullet when checkboxes are present?

Interesting.  I haven't tracked this down but exporting to LaTeX works
as it should but to beamer doesn't.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-206-g1bb9cf


signature.asc
Description: PGP signature

Re: [O] Key binding popup interface

[Eric S Fraga]

On Tuesday, 12 Dec 2017 at 14:02, Kaushal Modi wrote:
> Copying this on both Emacs devel and Org mode list. Hopefully this
> discussion is eligible for that.
>
> Problem statement: Need to have a pretty interface that shows the available
> valid key bindings.

which-key-mode works well for me.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-206-g1bb9cf


signature.asc
Description: PGP signature

[O] Lists with bullets and checkboxes in beamer

[Ken Mankoff]

Hi List,

I have some lists with checkboxes like this:

+ [X] Foo
+ [ ] Bar


When I export these to Beamer, I get both a bullet and a [] box. The bullet is 
redundant and adds noise to the slide. Is there a way to not have the bullet 
when checkboxes are present?

Thanks,

  -k.

Re: [O] Irrelevant src blocks can break noweb expansion

[Berry, Charles]

> On Dec 11, 2017, at 11:42 PM, Nicolas Goaziou  wrote:
> 
>> 
>> The irrelevant, unnamed, empty src block its consulted via
>> org-babel-get-src-block-info.
> 
> When? AFAICT, the second block doesn't contain any Noweb reference, so
> there is nothing to consult in the first place. IOW, something is
> missing in your recipe.

You are right. 

I had a problem with a subtree export seeming to fail at an unused src block 
and thought I had tracked it down to a bad header arg. But my example was 
clearly not right. And in trying the failed export again it worked. So I am 
deeply baffled.  If this problem shows up again, I'll do a better job of 
tracking it down.

Thanks,

Chuck

[O] Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list)

[Kaushal Modi]

Copying this on both Emacs devel and Org mode list. Hopefully this
discussion is eligible for that.

Problem statement: Need to have a pretty interface that shows the available
valid key bindings.

We have something custom developed for Org export interface. Magit has its
own popup interface. I know verilog-mode.el has something in-house for
picking the skeleton for insertion, but the interface is not as good as
hydra's.  Projectile.el (not on GNU Elpa) has its projectile commander,
another in-house attempt to get a similar pop-up interface.

Of all those options and more that I've seen out there, hydra.el looks like
the most elegant and *configurable* option.

Can hydra.el be merged into Emacs core, so that all the packages can start
taking advantage of that? We need to stop having each package develop their
own way to do this same thing.

It's already on GNU Elpa[1] , so there won't be any legal concerns.

[1]: https://elpa.gnu.org/packages/hydra.html

On Tue, Dec 12, 2017, 8:50 AM Rasmus  wrote:

> Nicolas Goaziou  writes:
>
> > Hello,
> >
> > Rasmus  writes:
> >
> >> Nicolas, are there any public interfaces to make ox export like
> >> interfaces?
> >
> > No, there isn't. However, Org provides `org-mks'.
>
> Good point.  It isn’t quite as nice as the export dispatcher.  Let’s wait
> and see what Eric prefers.
>
-- 

Kaushal Modi

Re: [O] Poll: new keybinding for org-insert-structure-template?

[Rasmus]

Nicolas Goaziou  writes:

> Hello,
>
> Rasmus  writes:
>
>> Nicolas, are there any public interfaces to make ox export like
>> interfaces?
>
> No, there isn't. However, Org provides `org-mks'.

Good point.  It isn’t quite as nice as the export dispatcher.  Let’s wait
and see what Eric prefers.

Rasmus

-- 
Send from my Emacs