Hello, Rasmus <ras...@gmx.us> writes:
> Changes are one sentence in the documentations, casing, and I changed > the regexp so that :only-contents is valid (it's nil). Thank you. It isn't very important, but you forgot full stops at the end of comments in the test file. > Is it better now? I think so. > I want to discuss one more important potential issue before having the > patch applied. Currently, location is ignored if the included part is > not an env (line 3381) and not a block (3392). I'm not sure this is > right. I could do one of the following: > > 1. Nothing (current state) > 2. Throw an error if location and env or block are combined. > 3. Try to use location even if block is set. Recall, though, that > location is resolved using org-mode. > 4. Let location be a general regexp if env or block is non-nil. > But then we are breaking with the org file-link idea. > 5. Make location work for org files when env or block, otherwise > throw an error. > > WDYT? I think option 1 is perfect. If a block with org contents is needed, one can always do #+begin_center #+include: "file.org::*headline" #+end_center Block and environments are really meant for literal insertion, where locations do not apply. > Less important. Should the <I "speedkey" (I don't know if that's the > right term) prompt for a location, or change the cursor position to > after the filename? The "right term" is structure template. Since those are configurable, I think the default, simple, behaviour is preferable. > + (only-contents > + (and (string-match ":only-contents *?\\([^: \r\t\n]\\S-*\\)?" > value) Is the shy *? necessary? Regards, -- Nicolas Goaziou
