[Orgmode] Re: Gmane readers - please subscribe
Ben Finney ben+em...@benfinney.id.au writes: Carsten Dominik carsten.domi...@gmail.com writes: If you are reading emacs-orgmode.org through gmane, please read this new FAQ to help take load off the maintainers. http://orgmode.org/worg/org-faq.php#ml-subscription-and-gmane A large part of my reason for reading via Gmane is to avoid yet another set of authentication credentials. Especially one that I never use; that's a security nightmare waiting to happen. So I'm not interested in increasing my security exposure by making a Mailman account on yet another site. Yikes! What nightmare awaits those of us who've foolishly gone ahead and subscribed? What's my exposure, beyond some nefarious cracker impersonating me on emacs-orgmode? Tyler ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [PATCH] (org-footnote): Added missing group definition and typos.
Applied, thanks. - Carsten On Apr 26, 2010, at 7:49 PM, Mikael Fornius wrote: --- lisp/org-footnote.el |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/lisp/org-footnote.el b/lisp/org-footnote.el index 84cd7b3..0f7168b 100644 --- a/lisp/org-footnote.el +++ b/lisp/org-footnote.el @@ -65,6 +65,11 @@ (org-re ^\\(\\[\\([0-9]+\\|fn:[-_[:word:]]+\\)\\]\\)) Regular expression matching the definition of a footnote.) +(defgroup org-footnote nil + Footnotes in Org-mode. + :tag Org Footnote + :group 'org) + (defcustom org-footnote-section Footnotes Outline heading containing footnote definitions before export. This can be nil, to place footnotes locally at the end of the current @@ -75,7 +80,7 @@ automatically, i.e. when creating the footnote, and when sorting the notes. However, by hand you may place definitions *anywhere*. If this is a string, during export, all subtrees starting with this heading will be removed after extracting footnote definitions. - :group 'org-footnotes + :group 'org-footnote :type '(choice (string :tag Collect footnotes under heading) (const :tag Define footnotes locally nil))) @@ -87,7 +92,7 @@ as in Org-mode. Outside Org-mode, new footnotes are always placed at the end of the file. When you normalize the notes, any line containing only this tag will be removed, a new one will be inserted at the end of the file, followed by the collected and normalized footnotes. - :group 'org-footnotes + :group 'org-footnote :type 'string) (defcustom org-footnote-define-inline nil -- 1.7.0.2 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Choosing external app at runtime?
On Apr 19, 2010, at 7:53 PM, Ali Tofigh wrote: On Sun, Apr 18, 2010 at 04:18, Simon Guest simon.gu...@tesujimath.org wrote: At Sun, 18 Apr 2010 08:24:41 +0200, Carsten Dominik wrote: On Apr 16, 2010, at 7:35 AM, Simon Guest wrote: When I follow a link, Org mode knows what application to use. Except that sometimes I want to override that choice. Currently we do not have this. I can see that this could be both useful and annoying, if you have to answer a prompt each time. If the choice was only offered when a C-u prefix was given, it wouldn't be annoying. This is a reasonable approach - but I don't know how the Emacs mailcap interface treats multiple matches. Who does? Currently we use the C-u prefix to force opening a link in Emacs, but we can find a solution here. A patch implementing the ability to select an application in this way would be seriously considered. - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Limited #+INCLUDE ?
On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison davi...@stats.ox.ac.uk wrote: I'm considering investigating the following and would appreciate comments on this idea. The aim is to make it easier to use Org-mode to work pure code files which are *external to Org-mode* (i.e. this proposal lies outside of the current org-babel tangling framework). - Extend Org file links to allow links to a range of lines in a file. The syntax could be [[file:/path/to/file::from::to][linkname]] +1 I like this idea, especially for exporting complex documents. If org-store-link were enhanced to generate links with this line information, I would probably use this a lot. - These links will bring up a buffer visiting the target file, narrowed to the target region. Or could be brought up with a wide view but with the region selected? - 'from' and 'to' could be line numbers, or regexps for text search. The latter could be quite appealing, although possibly a little fragile. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Bug: create latex png while export to HTML become very slow [6.35i]
Hi Lucas, thanks to some detective work by Ulf Stegemann and Nick Dokos we have now identified what was causing this slowdown. The new LaTeX setup in 6.35 led to the inclusion of more packages into the image generator. The worst offender was hyperref. In the latest git head, this problem has been removed by adding switches to the settings in org-export-latex-default-packages-alist and org-export-latex-packages-alist, as to whether the package needs to be included for snippet image creation. If you get the git version, or wait for 6.36 which will be release this weekend, HTML export of your files should basically happen at the old speeds again. Thank you for your report, and thanks to everyone who helped resolving the issue. - Carsten On Apr 15, 2010, at 6:38 PM, Lucas Peng wrote: Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. After upgrade to 6.35i, export .org file with latex fragment become extremly slow. Emacs : GNU Emacs 23.1.95.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.0) of 2010-04-05 on lucaspeng-laptop Package: Org-mode version 6.35i current state: == (setq org-export-with-LaTeX-fragments t org-export-latex-after-initial-vars-hook '(org-beamer-after-initial- vars) org-agenda-custom-commands '((h HomeWorks ((agenda ) (tags HOMEWORK) (tags STUDY))) ) org-agenda-files '(~/homework/wiki/todo.org) org-after-todo-state-change-hook '(org-clock-out-if-current) outline-minor-mode-prefix [(control o)] org-export-latex-format-toc-function 'org-export-latex-format-toc- default org-export-preprocess-hook '(org-export-blocks-preprocess) org-tab-first-hook '(org-hide-block-toggle-maybe) org-src-mode-hook '(org-src-mode-configure-edit-buffer) org-confirm-shell-link-function 'yes-or-no-p org-export-first-hook '(org-beamer-initialize-open-trackers) org-agenda-include-all-todo t org-todo-keywords '(TODO STARTED DONE) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide- drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-publish-project-alist '((wiki :base-directory ~/WikiNotes/org/ :base-extension org :publishing-directory ~/WikiNotes/publish/ :recursive t :publishing-function org-publish-org-to-html :section-numbers nil :auto-preamble t :table-of-contents nil :style link rel='stylesheet' type='text/css' href='css/ style.css' / :style-include-default t :author-info nil :email-info nil :creator-info nil) (wiki2 :base-directory ~/WikiNotes/org/ :base-extension css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\| swf :publishing-directory ~/WikiNotes/publish/ :recursive t :publishing-function org-publish-attachment) (website :components (wiki wiki2))) org-export-preprocess-before-normalizing-links-hook '(org-remove- file-link-modifiers) org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] turn-on-org-cdlatex) org-confirm-elisp-link-function 'yes-or-no-p org-occur-hook '(org-first-headline-recenter) org-export-preprocess-before-selecting-backend-code-hook '(org- beamer-select-beamer-code) org-remember-templates '((Tasks 116 * TODO %?\n %i\n %a /home/lucaspeng/homework/wiki/todo.org nil) (Appointments 97 * Appointment: %?\n%^T\n%i\n %a ~/organizer.org nil) ) org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix- toc org-beamer-auto-fragile-frames org-beamer-place-default-actions-for-lists) ) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] org-html link building diff
On Apr 26, 2010, at 9:45 PM, Tom Breton (Tehom) wrote: I am sure it does - the export function has grown like cancer in the run of years. Unfortunately, I right now do not have the time to study this carefully enough to make sure this does not break anything. Tom, maybe you can update the patch to the current master. What I meant here is that you rebase your patch to the current origin/ master and republish it. I have made some small changes to the HTML exporter (should not have conflicts with your changes, I hope...) Actually, I don't seem to be able to push to the repository. Unfortch, my machine isn't that great for hosting a public repository, as the instructions suggest. Is there something I need to do? Yes. Send me your name on repo.or.cz and I'll add push for you. Please create your own branch and stay on it. Or did you mean, base it on the current version of org? I thought I had because I had just pulled it. Are there any volunteers who can put this patch through the mill? Or Tom, maybe you first want to implement the other stuff you are thinking about? That's half-done already; * Mostly, I made the other branches of `cond' use `org-html-make-link' too. That's done. * I'd like to cleanup the test whether to inline images. My first patch had copied it more or less unchanged from what it was. Now the bulk of the test is encapsulated in `org-html-should-inline-p', but I've yet to make the code use it. * And I'd like to make the two sources of name conversion respect each other. * There are now two sources of name conversion: * The existing code to convert org files which operates if `org-export-html-link-org-files-as-html' is non-nil. * This changes url type as well as url path * org-html-cvt-link-fn, which supports converting via a lookup table or similar. I need that for org2blog, which posts to a Blogger-style blog directly from org. * Presently this does not treat url type. * (For completeness) And it can not convert the name at all. * So `org-html-cvt-link-fn' signature may change in the near future, and I'll probably encapsulate the other conversion, and then the logic will just be choose one by precedence. A couple of notes: * I am taking to make sure this does not break anything to heart and I will write some semblance of a test suite for org-html. I'll post that soon. Awesome. As you have noticed, image inclusion has a number of special cases which I have added over the years and I don't even remember everyting in there. Important things: - Inlining is an issue - attribute handling - figure captions and references to figures Everybody, please feel free to contribute any tests of the proper current behavior to it. * Potential snippage: * There is a FIXME comment in `org-export-as-html' that's been there for a long time. I suspect it's been fixed, because I haven't encountered a problem about not escaping something. * FIXME: do we need to unescape here somewhere? Yes, this can be removed - we have not had a problem here for quite a while. * I don't believe the code just before the `cond' still adds anything useful. It seems redundant to other code. But I'd like to hear from others before I dare snip it out. That is, the code that begins ;; Make an image out of the description if that is so wanted This is for having a clickable Thumbnail - I am not sure if this is also handled elsewhere. Thanks Tom, for taking a look at this mess. - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Why does org-html.org refuse to export a table of contents when body-only is t?
On Apr 18, 2010, at 7:32 PM, Jan Böcker wrote: Hi all, I'd like to add a table of contents to a HTML export with body-only set to t (to feed into jekyll later), but org-html.el automatically disables the TOC when body-only is given. I have used the attached one-line patch without any problems, the (still XHTML strict compliant) result can be seen here: http://www.jboecker.de/2010/04/14/general-reference-filing-with-org-mode.html gitk tells me that the line I have changed was first introduced in Release 4.75, so is this just a use case that was not thought of when this was programmed, or is there a specific reason? The reason for this behavior is that the most frequent application for this seems to me to convert a small block to HTML, to paste it somewhere else. But I have no string reasons to keep it like this. Do we have more opinions on this issue? - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [patch] org-agenda-goto should push mark before moving point
Hi Andreas, I have applied your patch. Thanks. - Carsten On Apr 23, 2010, at 10:42 AM, Andreas Seltenreich wrote: Carsten Dominik writes: On Apr 22, 2010, at 10:57 PM, Andreas Seltenreich wrote: (switch-to-buffer-other-window buffer) (widen) + (push-mark) (goto-char pos) I am no sure this is the right thing to do. Because, often you will show *many* places from the agenda before going back to the buffer. Org-agenda-goto is called by many other functions like org-agenda- show, org-agenda-recenter etc. Well, I'd prefer too many marks over too few. Popping multiple marks off the local mark ring is still faster than moving point around manually. This might work better: (defun my-org-agenda () (interactive) (push-mark) (call-interactively 'org-agenda)) (define-key global-map \C-ca 'my-org-agenda) Maybe you can test this and report back? Won't work for me since most of the time I don't call the Agenda from the affected buffers. I guess advising goto-char and checking the backtrace for org-agenda-goto isn't a good idea either since goto-char is a C function... I'm afraid having git merge along that change indefinitely is the only option for me as long as I'm the only one deeming it a good thing. Thanks, andreas - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Gmane readers - please subscribe
Tyler Smith tyler.sm...@eku.edu writes: Ben Finney ben+em...@benfinney.id.au writes: A large part of my reason for reading via Gmane is to avoid yet another set of authentication credentials. Especially one that I never use; that's a security nightmare waiting to happen. So I'm not interested in increasing my security exposure by making a Mailman account on yet another site. Yikes! What nightmare awaits those of us who've foolishly gone ahead and subscribed? What's my exposure, beyond some nefarious cracker impersonating me on emacs-orgmode? The assumption here is that logging into the mailing list account is something done infrequently to never for any given user. That's certainly the case for just about any list I've subscribed to. For an infrequently-to-never used passphrase, one of two things is the case: either it's unique, or it is identical to the passphrase that accesses some other set of services for the user. Since it's an infrequently-to-never accessed service, it's an unreasonable burden to expect the user to maintain unique passphrases for every such service. If for this list, why not for every such list? So what usually ends up happening is they're identical for a given person across many different services. But the more that's the case, the greater the exposure: any one of those services could manage their security poorly, or simply be unlucky enough to attract a bored and/or motivated cracker; and a compromise on any one of them removes any expectation of security on any of the rest of the services where the user has the same passphrase. The sensible policy, therefore, is to cull the proliferation of such passphrase-requiring infrequently-to-never-accessed accounts. Which, in turn, means saying a polite “no thank you” to most requests to set up new accounts. -- \“The greatest tragedy in mankind's entire history may be the | `\ hijacking of morality by religion.” —Arthur C. Clarke, 1991 | _o__) | Ben Finney ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Suggestions needed for handling ideas
Hi Ali, John and all, Ali Tofigh wrote: On Sun, Apr 25, 2010 at 03:46, John Wiegley jwieg...@gmail.com wrote: Frequently my notes on meetings contain ideas for stuff to try. Does anyone have any advice on how to handle these? For ideas I just use a done TODO state called NOTE. I have the key M-z bound to create one and switch me to the Org-buffer, so that I can stay there and keep typing. Thanks for the suggestion. I've tried both checkboxes and TODO items to keep track of my ideas, but your idea of using a done state seems very neat. I've another view on this subject -- but I've to be honest at this early stage: *I currently have no solution that completely satisfies me*. I really am puzzled by using a TODO state for saying this is a note. For me, a so-called TODO state is a circumstance (or a mode), so one transitional property on a cycle. That's something that evolves over time, such as: TODO - NEXT - STARTED - WAITING - DONE A NOTE does not belong to such cycles. It's just some kind of property. I would be more inclined to view a NOTE property as a tag, but that does not satisfy me neither. Tags are for contexts, mainly resources we need to have at hand, or locations we need to be, or time ranges in which the action makes sense. Maybe it should be a real PROPERTY? Anyway, as I don't have the solution yet, I don't have yet a proper way to mark my notes as NOTES... I hope others can share their views on this? Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Limited #+INCLUDE ?
This functionality would be really useful. Since it is more directly applicable for programming, then maybe an easier approach to implement it would be just a link to a function in a file. For instance [[file_def:/path/to/file::definition_name][linkname]] Org could rely on the capability of the target major-mode to select the region enclosing the function (c-mark-function for C/C++, py-mark-def-or-class for python, mark-defun for lisp, etc.). This would avoid the necessity of including commenting marks in the code and although it would be limited to a function body at a time it would be enough in many situations. Darlan 2010/4/27 Eric S Fraga ucec...@ucl.ac.uk: On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison davi...@stats.ox.ac.uk wrote: I'm considering investigating the following and would appreciate comments on this idea. The aim is to make it easier to use Org-mode to work pure code files which are *external to Org-mode* (i.e. this proposal lies outside of the current org-babel tangling framework). - Extend Org file links to allow links to a range of lines in a file. The syntax could be [[file:/path/to/file::from::to][linkname]] +1 I like this idea, especially for exporting complex documents. If org-store-link were enhanced to generate links with this line information, I would probably use this a lot. - These links will bring up a buffer visiting the target file, narrowed to the target region. Or could be brought up with a wide view but with the region selected? - 'from' and 'to' could be line numbers, or regexps for text search. The latter could be quite appealing, although possibly a little fragile. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode -- Darlan Cavalcante Moreira SDR4all, a new way of teaching telecommunications: http://www.sdr4all.com/ ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Gmane readers - please subscribe
Ben Finney ben+em...@benfinney.id.au writes: Since it's an infrequently-to-never accessed service, it's an unreasonable burden to expect the user to maintain unique passphrases for every such service. If for this list, why not for every such list? It's easy to maintain unique passphrases, and to create them. There's enough software out there. I use my own litty tool, which runs on windows and Linux (I have no mac to compile wxWidgets stuff there...). There's a portable app out somewhere... google ... http://portableapps.com/apps/utilities/keepass_portable Sebastian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Gmane readers - please subscribe
Sebastian Rose sebastian_r...@gmx.de writes: Ben Finney ben+em...@benfinney.id.au writes: Since it's an infrequently-to-never accessed service, it's an unreasonable burden to expect the user to maintain unique passphrases for every such service. If for this list, why not for every such list? It's easy to maintain unique passphrases, and to create them. Having done so for many accounts and using many different systems for doing so, I can assure you that it's easier and more reliable to just avoid creating such accounts where possible. -- \“I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.” —Douglas Adams | Ben Finney ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Gmane readers - please subscribe
Ben Finney ben+em...@benfinney.id.au wrote: A large part of my reason for reading via Gmane is to avoid yet another set of authentication credentials. Especially one that I never use; that's a security nightmare waiting to happen. So I'm not interested in increasing my security exposure by making a Mailman account on yet another site. Yikes! What nightmare awaits those of us who've foolishly gone ahead and subscribed? What's my exposure, beyond some nefarious cracker impersonating me on emacs-orgmode? The assumption here is that logging into the mailing list account is something done infrequently to never for any given user. That's certainly the case for just about any list I've subscribed to. For an infrequently-to-never used passphrase, one of two things is the case: either it's unique, or it is identical to the passphrase that accesses some other set of services for the user. Since it's an infrequently-to-never accessed service, it's an unreasonable burden to expect the user to maintain unique passphrases for every such service. If for this list, why not for every such list? So what usually ends up happening is they're identical for a given person across many different services. But the more that's the case, the greater the exposure: any one of those services could manage their security poorly, or simply be unlucky enough to attract a bored and/or motivated cracker; and a compromise on any one of them removes any expectation of security on any of the rest of the services where the user has the same passphrase. The sensible policy, therefore, is to cull the proliferation of such passphrase-requiring infrequently-to-never-accessed accounts. Which, in turn, means saying a polite “no thank you” to most requests to set up new accounts. The common policy, however, is that you subscribe to the mailing list with the defaults, use the automatically gener- ated password to set the account to no mail and never bother again. Some mailing lists will send you a reminder of your account's subscriptions once a month, some not even that. And should you really ever need to access your ac- count's configuration, you can always use the lost pass- word link. Tim ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Gmane readers - please subscribe
Ben Finney ben+em...@benfinney.id.au wrote: Tyler Smith tyler.sm...@eku.edu writes: Ben Finney ben+em...@benfinney.id.au writes: A large part of my reason for reading via Gmane is to avoid yet another set of authentication credentials. Especially one that I never use; that's a security nightmare waiting to happen. So I'm not interested in increasing my security exposure by making a Mailman account on yet another site. Yikes! What nightmare awaits those of us who've foolishly gone ahead and subscribed? What's my exposure, beyond some nefarious cracker impersonating me on emacs-orgmode? The assumption here is that logging into the mailing list account is something done infrequently to never for any given user. That's certainly the case for just about any list I've subscribed to. For an infrequently-to-never used passphrase, one of two things is the case: either it's unique, or it is identical to the passphrase that accesses some other set of services for the user. Since it's an infrequently-to-never accessed service, it's an unreasonable burden to expect the user to maintain unique passphrases for every such service. If for this list, why not for every such list? Why not indeed? See below. So what usually ends up happening is they're identical for a given person across many different services. But the more that's the case, the greater the exposure: any one of those services could manage their security poorly, or simply be unlucky enough to attract a bored and/or motivated cracker; and a compromise on any one of them removes any expectation of security on any of the rest of the services where the user has the same passphrase. The sensible policy, therefore, is to cull the proliferation of such passphrase-requiring infrequently-to-never-accessed accounts. Which, in turn, means saying a polite “no thank you” to most requests to set up new accounts. It seems to me that another sensible policy is to generate a random password, set it and forget it. If I ever need it, I use the password reminder mechanism. The policy has the advantage of reducing the load on the administrators. The disadvantage is that I have to wait a few minutes before I can make changes. I'm perfectly willing to make that trade-off. The most serious problem with this approach is how to generate a password that obeys whatever stupid (and in many cases, undocumented) restrictions the program designer imposes on acceptable passwords. Witn mailman, you can let *it* generate the password. There may be other problems of course that I have not thought about. I also sympathize with your point of view[1]: there are many cases where I *have* to have another password and it drives me up the wall, but in this one case, I really don't mind. Nick [1] For mailman in particular, Jamie Zawinski published an essay entitled Mailman considered harmful, attacking the mailman password policy (among other things): http://www.jwz.org/doc/mailman.html Barry Warsaw's rebuttal is here: http://www.gnu.org/software/mailman/jwzrebuttal.html ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Limited #+INCLUDE ?
Darlan Cavalcante Moreira darc...@gmail.com writes: This functionality would be really useful. Since it is more directly applicable for programming, then maybe an easier approach to implement it would be just a link to a function in a file. For instance [[file_def:/path/to/file::definition_name][linkname]] Org could rely on the capability of the target major-mode to select the region enclosing the function (c-mark-function for C/C++, py-mark-def-or-class for python, mark-defun for lisp, etc.). This would avoid the necessity of including commenting marks in the code and although it would be limited to a function body at a time it would be enough in many situations. Following in this major mode specific behavior direction, maybe it would be possible to make use of the tags functionality for linking to specific functions, chapters, etc... based on the mode of the target file. (info (emacs)Tags) ;; how great is it that gnus resolves these links Tags would allow for robust links to points in changing files without the need to place text anchors into the files themselves. The immediate downside is that tags rely on a TAGS table to resolve links. This table can easily be ignored from version control (for collaboration). Then Org-mode could use the `find-tag' function to resolve it's links, maybe in combination with the function delimiting features Darlan mentioned above to references entire function/object ranges. -- Eric Darlan 2010/4/27 Eric S Fraga ucec...@ucl.ac.uk: On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison davi...@stats.ox.ac.uk wrote: I'm considering investigating the following and would appreciate comments on this idea. The aim is to make it easier to use Org-mode to work pure code files which are *external to Org-mode* (i.e. this proposal lies outside of the current org-babel tangling framework). - Extend Org file links to allow links to a range of lines in a file. The syntax could be [[file:/path/to/file::from::to][linkname]] +1 I like this idea, especially for exporting complex documents. If org-store-link were enhanced to generate links with this line information, I would probably use this a lot. - These links will bring up a buffer visiting the target file, narrowed to the target region. Or could be brought up with a wide view but with the region selected? - 'from' and 'to' could be line numbers, or regexps for text search. The latter could be quite appealing, although possibly a little fragile. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Gmane readers - please subscribe
On Tue, 27 Apr 2010 20:02:50 +1000
Ben Finney ben+em...@benfinney.id.au wrote:
[...]
For an infrequently-to-never used passphrase, one of two things is the
case: either it's unique, or it is identical to the passphrase that
accesses some other set of services for the user.
Since it's an infrequently-to-never accessed service, it's an
unreasonable burden to expect the user to maintain unique passphrases
for every such service. If for this list, why not for every such list?
An idea to generate unique passwords for different services is to take
the first N characters of the hash of a string that is the
concatenation of the domain name and a master password.
I have a page on my site that does just that in javascript.
No need to maintain anything.
Frequently used passwords are stored in firefox or occasionally even in
my head.
The equivalent bash command I use for the orgmode list is:
echo -n masterpasswordlists.gnu.org | md5sum | awk '{print substr ($1,0,7)}'
Andreas
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Can org accept letter (a.b.c) as ordered list?
Hello Experts, I'm wondering if it's easy to make ordered list like this: 1. This is the first level a. This is in the second level b. Same level c. Same ... 2. This is the first level again It is more readable than the current one. Thanks! Xin ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Gmane readers - please subscribe
The sensible policy, therefore, is to cull the proliferation of such passphrase-requiring infrequently-to-never-accessed accounts. Which, in turn, means saying a polite “no thank you” to most requests to set up new accounts. OK - there _must_ be a missunderstanding... The sensible thing in world full of unsubscribed people is to _not_ run such a system like this at all. It simply wouldn't work in such a spam-free way. How do you suppose mails of unsubscribed users get here? Is it the work of some anonymous maintainers on gmane.org, he? No! It is the work of people on this list - those who volunteered to read mails of unsubscribed users, filter out spam and forward the rest, so they could possibly find help on this list. Every day heroes, that even dare to have an account with a password :) and, seriously now, do a real great job! We all post via reply all to support unsubscribed users. They (you?) couldn't discuss in realtime otherwise. Sorry Sebastian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Problem with sectioning function for LaTeX export
On Apr 18, 2010, at 12:05 PM, Sebastian Hofer wrote:
Hi all,
I'm trying to write my own sectioning function for latex export of
my CV. What it does is to read out some property of the given
headline and pass it to a latex command:
(defun my-org-cv-sectioning (lvl heading)
(let ((year)
(formatlist)
(cleanheading (substring-no-properties heading 1)))
(with-current-buffer (org-find-base-buffer-visiting cv.org)
(let ((headingpoint (find-custom-id cleanheading)))
(if headingpoint
(progn
(goto-char headingpoint)
(setq year (org-entry-get nil YEAR))
(setq formatlist (nth (- 1 lvl) my-org-cv-sectioning-list))
(list cleanheading
(format (car formatlist) (if year year ) cleanheading)
(format (car (cdr formatlist)) (if year year )
cleanheading
The function find-custom-id returns the point of the heading, my-org-
cv-sectioning list contains the customized latex commands. As you
may see, I'm an elisp newbie, so excuse the coding style, or even
better, make suggestions for improvements! There might be a much
nicer way to read out the wanted properties (also cf. point 2
below), so if you have any suggestions on that, I would be glad to
hear them!
Anyway, there are currently two problems:
- The function reads out the properties correctly, but the export
command throws an error. So I guess I'm not getting the format of
the output right, but I can't really make sense of the description
in the org-export-latex-classes docstring. Currently the function is
returning something like this: (Heading (\section[year]{Heading}
\section*[year]{Heading})). Isn't this what it's supposed to look
like? The error message is the following:
I think it must be
(Heading \section[year]{%s} \section*[year]{%s})
Note the %s for the heading, and also it i just one flat list of 3
items.
And yes, this is not too well documented.
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
format(nil Heading )
org-export-latex-subcontent(snipped)
org-export-latex-sub(snipped)
org-export-latex-global(((snipped
org-export-as-latex(nil nil nil *Org LaTeX Export*)
org-export-as-latex-to-buffer(nil)
call-interactively(org-export-as-latex-to-buffer)
org-export(nil)
call-interactively(org-export nil nil)
- As you can see I am using org-find-base-buffer-visiting find the
buffer of the org file, but of course its argument can't stay
hardcoded like this. I could also use the org mapping function, but
still I would need filename. Can someone give me a hint how to solve
this in a nice way?
Use
(org-find-base-buffer-visiting org-current-export-file)
HTH
- Carsten
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Agenda View window splits vertically
Guys, I'm newbie in emacs. Could please advice. Somehow I get my agenda view appears vertically, i.e from the right side from my org file. I open org file then press C-c a and I see Agenda Commands in the window to the right, not to the bottom as it was before. Could you please advice, how to make it back and make agenda view open horizontally? Thank you, Juri. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Agenda View window splits vertically
Juri Artamonov jartamo...@gmail.com wrote: I'm newbie in emacs. Could please advice. Somehow I get my agenda view appears vertically, i.e from the right side from my org file. I open org file then press C-c a and I see Agenda Commands in the window to the right, not to the bottom as it was before. Could you please advice, how to make it back and make agenda view open horizontally? The following is pure guesswork, unencumberd by reliance on facts or other such minor considerations: What does ``C-h f org-prepare-agenda RET'' say? If it says that the function is advised, then that might be what's doing it: find the advice and get rid of it. HTH, Nick ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Limited #+INCLUDE ?
Eric Schulte schulte.e...@gmail.com writes: Darlan Cavalcante Moreira darc...@gmail.com writes: This functionality would be really useful. Since it is more directly applicable for programming, then maybe an easier approach to implement it would be just a link to a function in a file. For instance [[file_def:/path/to/file::definition_name][linkname]] Org could rely on the capability of the target major-mode to select the region enclosing the function (c-mark-function for C/C++, py-mark-def-or-class for python, mark-defun for lisp, etc.). This would avoid the necessity of including commenting marks in the code and although it would be limited to a function body at a time it would be enough in many situations. Following in this major mode specific behavior direction, maybe it would be possible to make use of the tags functionality for linking to specific functions, chapters, etc... based on the mode of the target file. This sounds like an interesting idea; I have been meaning to use tags more. However, I wouldn't want to exclude the possibility of using this functionality in a non-programming context -- i.e. collaborative editing of arbitrary text documents -- which would argue for approaches based on storing arbitrary text context using Emacs bookmarks or custom text searches. Perhaps the new functionality could involve a choice of more than one new Org link type? Dan (info (emacs)Tags) ;; how great is it that gnus resolves these links Tags would allow for robust links to points in changing files without the need to place text anchors into the files themselves. The immediate downside is that tags rely on a TAGS table to resolve links. This table can easily be ignored from version control (for collaboration). Then Org-mode could use the `find-tag' function to resolve it's links, maybe in combination with the function delimiting features Darlan mentioned above to references entire function/object ranges. -- Eric Darlan 2010/4/27 Eric S Fraga ucec...@ucl.ac.uk: On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison davi...@stats.ox.ac.uk wrote: I'm considering investigating the following and would appreciate comments on this idea. The aim is to make it easier to use Org-mode to work pure code files which are *external to Org-mode* (i.e. this proposal lies outside of the current org-babel tangling framework). - Extend Org file links to allow links to a range of lines in a file. The syntax could be [[file:/path/to/file::from::to][linkname]] +1 I like this idea, especially for exporting complex documents. If org-store-link were enhanced to generate links with this line information, I would probably use this a lot. - These links will bring up a buffer visiting the target file, narrowed to the target region. Or could be brought up with a wide view but with the region selected? - 'from' and 'to' could be line numbers, or regexps for text search. The latter could be quite appealing, although possibly a little fragile. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Why does org-html.org refuse to export a table of contents when body-only is t?
At Tue, 27 Apr 2010 11:55:44 +0200, Carsten Dominik wrote: On Apr 18, 2010, at 7:32 PM, Jan Böcker wrote: Hi all, I'd like to add a table of contents to a HTML export with body-only set to t (to feed into jekyll later), but org-html.el automatically disables the TOC when body-only is given. I have used the attached one-line patch without any problems, the (still XHTML strict compliant) result can be seen here: http://www.jboecker.de/2010/04/14/general-reference-filing-with-org-mode.html gitk tells me that the line I have changed was first introduced in Release 4.75, so is this just a use case that was not thought of when this was programmed, or is there a specific reason? The reason for this behavior is that the most frequent application for this seems to me to convert a small block to HTML, to paste it somewhere else. But I have no string reasons to keep it like this. Do we have more opinions on this issue? Yes, the prospected exporter to atom uses body only to create html markup for a atom feed entry where it normally makes no sense to publish a table of contents. Same is true for org-mime and the Send html messages with Wanderlust hack. So maybe create a body without toc when body-only is set to t and create a body with toc when body-only is the symbol 'include-toc. HTH -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgp2ZdY2FvG6Q.pgp Description: PGP signature ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Limited #+INCLUDE ?
Another way to look at it is that this is an annotation mechanism. It can be used for any type of file or buffer. This would include text, websites (i.e. pointing to and annotating documents on the web), dired, source code, org files, html source, etc. Modifying existing link syntax will be difficult, especially because there might be additional features we need a year or two from now. For maximum flexibility and simplicity, this might be a good first use of extensible syntax. Samuel -- Q: How many CDC scientists does it take to change a lightbulb? A: You only think it's dark. [CDC has denied a deadly disease for 25 years] == Retrovirus: http://www.wpinstitute.org/xmrv/index.html ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Limited #+INCLUDE ?
Dan Davison davi...@stats.ox.ac.uk writes: Eric Schulte schulte.e...@gmail.com writes: Darlan Cavalcante Moreira darc...@gmail.com writes: This functionality would be really useful. Since it is more directly applicable for programming, then maybe an easier approach to implement it would be just a link to a function in a file. For instance [[file_def:/path/to/file::definition_name][linkname]] Org could rely on the capability of the target major-mode to select the region enclosing the function (c-mark-function for C/C++, py-mark-def-or-class for python, mark-defun for lisp, etc.). This would avoid the necessity of including commenting marks in the code and although it would be limited to a function body at a time it would be enough in many situations. Following in this major mode specific behavior direction, maybe it would be possible to make use of the tags functionality for linking to specific functions, chapters, etc... based on the mode of the target file. This sounds like an interesting idea; I have been meaning to use tags more. However, I wouldn't want to exclude the possibility of using this functionality in a non-programming context I agree that would be an unwelcome restriction, however maybe TAGS are not restricted to programming text ,[from (emacs) Tags ] | A tag is a reference to a subunit in a program or in a document. In | program source code, tags reference syntactic elements of the program: | functions, subroutines, data types, macros, etc. In a document, tags | reference chapters, sections, appendices, etc. Each tag specifies the | name of the file where the corresponding subunit is defined, and the | position of the subunit's definition in that file. ` also, they support general regexp tag specification through which they can be extended to arbitrary major modes. -- Eric -- i.e. collaborative editing of arbitrary text documents -- which would argue for approaches based on storing arbitrary text context using Emacs bookmarks or custom text searches. Perhaps the new functionality could involve a choice of more than one new Org link type? Dan (info (emacs)Tags) ;; how great is it that gnus resolves these links Tags would allow for robust links to points in changing files without the need to place text anchors into the files themselves. The immediate downside is that tags rely on a TAGS table to resolve links. This table can easily be ignored from version control (for collaboration). Then Org-mode could use the `find-tag' function to resolve it's links, maybe in combination with the function delimiting features Darlan mentioned above to references entire function/object ranges. -- Eric Darlan 2010/4/27 Eric S Fraga ucec...@ucl.ac.uk: On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison davi...@stats.ox.ac.uk wrote: I'm considering investigating the following and would appreciate comments on this idea. The aim is to make it easier to use Org-mode to work pure code files which are *external to Org-mode* (i.e. this proposal lies outside of the current org-babel tangling framework). - Extend Org file links to allow links to a range of lines in a file. The syntax could be [[file:/path/to/file::from::to][linkname]] +1 I like this idea, especially for exporting complex documents. If org-store-link were enhanced to generate links with this line information, I would probably use this a lot. - These links will bring up a buffer visiting the target file, narrowed to the target region. Or could be brought up with a wide view but with the region selected? - 'from' and 'to' could be line numbers, or regexps for text search. The latter could be quite appealing, although possibly a little fragile. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] org-mime - issues and remarks
At Mon, 26 Apr 2010 10:04:12 -0600, Eric Schulte wrote: David Maus dm...@ictsoc.de writes: While skimming the source code of org-mime I noticed two severe issues with regards to the MIME specifications: - when creating an attachment for a image org-mime (still) uses the file extension as MIME media subtype for Gnus messages. This not in compliance with RFC 2046. As mentioned before org-mime should/could use the function to determine MIME media type of message-mode and mime-edit-mode respectively. For SEMI the function is `mime-find-file-type', called with the file name as argument and returns a list whose first element is a string with MIME media type and second element is MIME media subtype. Alright, once I find the appropriate similar function in mml/gnus I will make this change. Well, I tried to change it for SEMI but this would require a complete rewrite of `org-mime-replace-images' because `mime-find-file-type' modifies the match-data and the `replace-regexp-in-string' get's confused (i.e.: throws an error). I'll see if I can come up with something w/o rewriting to much. Furthermore there are some minor glitches: - the filename parameter is only defined for the content-disposition header field; because images are attachments they can/should be easily send with content-disposition: attachment; filename=filename For SEMI (replace _ by -): __[[type/subtype content-disposition: attachment; filename=filename][base64]] could you expand upon this point, what's the problem? Hm. I noticed that in the test mail of Eric Fraga[1] images where attached as: , | Content-Type: application/octet-stream; type=image/png | Content-ID: _home_ucecesf_s_test_mip.png; filename=/home/ucecesf/s/test/mip.png | Content-Transfer-Encoding: base64 ` I.e. with the 'filename=' parameter in the Content-ID MIME header field. That wouldn't be correct or, say, not entirely correct because the filename option is only defined in a Content-Disposition MIME header field. So, the old story: It's out of the scope of MIME so you don't know what receiving clients will do. Anyway, org-mime currently does not put a filename parameter at all so what's only left is to send attached images with SEMI is Disposition: attachment like Gnus does. The difference: The Content-Disposition MIME header field contains an optional hint for the receiving MUA what to do with attached files. - 'inline' :: Show attachment without user interaction. - 'attachment' :: Show attachment only with explicit user interaction. For the attached images we don't want them to be shown without user interaction but rendered in the html markup. Sending them with Disposition: inline could result in a MUA showing the images inside the html markup and again maybe at the bottom of the message. - org-mime uses `reporter-compose-outgoing' to open a new message draft. This is not a could solution because (a) org-mine does not want to send a bug report and (b) would depend on reporter.el without necessity. I don't think this is a problem, I think reporter.el is the best approach here. Yes, I admit this is somewhat pedantic and hypothetical: If you depend on reporter that you should say so (require 'reporter) and you will depend on this particular implementation of `reporter-compose-outgoing'. As soon as this function does something else or something more, strange things might happen. It's like taking a detour: When we prepare the message draft we already know which functions are required depending on `org-mime-library'. HTH -- David [1] mid:87hbndq0ym.wl%ucec...@ucl.ac.uk -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgp0kkSw1ng7L.pgp Description: PGP signature ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Agenda View window splits vertically
At Tue, 27 Apr 2010 17:43:35 +0300, Juri Artamonov wrote: I'm newbie in emacs. Could please advice. Somehow I get my agenda view appears vertically, i.e from the right side from my org file. I open org file then press C-c a and I see Agenda Commands in the window to the right, not to the bottom as it was before. Could you please advice, how to make it back and make agenda view open horizontally? You might check the two variables `split-height-threshold' and `split-width-threshold' that could be used to determine whether to split the window vertically or horizontically: M-x apropos RET split-window-sensibly RET , | split-window-sensibly is a compiled Lisp function in `window.el'. | | (split-window-sensibly window) | | Split window in a way suitable for `display-buffer'. | If `split-height-threshold' specifies an integer, window is at | least `split-height-threshold' lines tall and can be split | vertically, split window into two windows one above the other and | return the lower window. Otherwise, if `split-width-threshold' | specifies an integer, window is at least `split-width-threshold' | columns wide and can be split horizontally, split window into two | windows side by side and return the window on the right. If this | can't be done either and window is the only window on its frame, | try to split window vertically disregarding any value specified | by `split-height-threshold'. If that succeeds, return the lower | window. Return nil otherwise. | | By default `display-buffer' routines call this function to split | the largest or least recently used window. To change the default | customize the option `split-window-preferred-function'. | | You can enforce this function to not split window horizontally, | by setting (or binding) the variable `split-width-threshold' to | nil. If, in addition, you set `split-height-threshold' to zero, | chances increase that this function does split window vertically. | | In order to not split window vertically, set (or bind) the | variable `split-height-threshold' to nil. Additionally, you can | set `split-width-threshold' to zero to make a horizontal split | more likely to occur. | | Have a look at the function `window-splittable-p' if you want to | know how `split-window-sensibly' determines whether window can be | split. ` HTH -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpvPoxGbZDco.pgp Description: PGP signature ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Gmane readers - please subscribe
Ben Finney ben+em...@benfinney.id.au writes: Sebastian Rose sebastian_r...@gmx.de writes: Ben Finney ben+em...@benfinney.id.au writes: Since it's an infrequently-to-never accessed service, it's an unreasonable burden to expect the user to maintain unique passphrases for every such service. If for this list, why not for every such list? It's easy to maintain unique passphrases, and to create them. Having done so for many accounts and using many different systems for doing so, I can assure you that it's easier and more reliable to just avoid creating such accounts where possible. Other have already made some excellent suggestions. About multiple system issue: you could look at a web based password manager like passpack.com or such. Regards -- Manish ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Limited #+INCLUDE ?
Dan Davison davi...@stats.ox.ac.uk writes: This sounds like an interesting idea; I have been meaning to use tags more. However, I wouldn't want to exclude the possibility of using this functionality in a non-programming context -- i.e. collaborative editing of arbitrary text documents -- which would argue for approaches based on storing arbitrary text context using Emacs bookmarks or custom text searches. Perhaps the new functionality could involve a choice of more than one new Org link type? The non-programming context actually suits my original requirement better than the major-mode version. Because of the nature of the course its not uncommon to be working in a language which does not play nicely with a major mode: recent example Java Markup Language which is held as comments in a java class file. -- Giles ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Alignment problem with org-format-org-table-html
When creating a table, I was noticing that the colgroupcol... provides useful alignment information based on whether or not the column has numbers in it. I think, however, that there is a mistake in this routine. Take, for example, the following table: | Id | Task | Developer | Estimate | Spent | Remaining | Comp.% | Updated | |-+--+---+--+---+---++-| | 1 | Task One | SLP |1 | 0 | 1 | 0 | SLP, 2010-04-27 | | 2 | Task Two | SLP |1 | 0 | 1 | 0 | SLP, 2010-04-27 | | 3 | Task Three | SLP |2 | 0 | 2 | 0 | SLP, 2010-04-27 | | 4 | Task Four| SLP |2 | 0 | 2 | 0 | SLP, 2010-04-27 | | 5 | Task Five| SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 | | 5.1 | Another Task | XML team |0 | 1 | 0 | 0 | SLP, 2010-04-27 | | 6 | Task Six | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 | | 6.1 | More Tasks | DB team |3 | 0 | 3 | 0 | SLP, 2010-04-27 | | 7 | Task Seven | SLP |3 | 0 | 3 | 0 | SLP, 2010-04-27 | When the colgroup list is created for this table, it reads: colgroupcol align=right /col align=left /col align=left /col align=right /col align=right /col align=left /col align=left /col align=left / /colgroup Note that the first columns are correct, but the last few are not. It should read right, left, left, right, right, right, right, left. I believe that this is due to the ( i nline) comparison within org-format-org-table-html, which is nonsensical because it's trying to compare a column number with a number of rows. I've attached a patch for the problem. diff --git a/lisp/org-html.el b/lisp/org-html.el index 3ac2b18..0ffde15 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -1659,8 +1659,7 @@ lang=\%s\ xml:lang=\%s\ (mapconcat (lambda (x) (setq i (1+ i)) -(if (and ( i nline) - (string-match org-table-number-regexp x)) +(if (string-match org-table-number-regexp x) (incf (aref fnum i))) (cond (head ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Agenda View window splits vertically
Juri Artamonov writes: Guys, I'm newbie in emacs. Could please advice. Somehow I get my agenda view appears vertically, i.e from the right side from my org file. I open org file then press C-c a and I see Agenda Commands in the window to the right, not to the bottom as it was before. Could you please advice, how to make it back and make agenda view open horizontally? I suspect I did not quite understand but this might help: http://orgmode.org/worg/org-hacks.php#sec-8 HTH -- Manish ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: due today notification
Hi Buck, Buck Brody buckbr...@gmail.com writes: Sorry, I don't think I properly described what I am looking for. I want a visual indicator (like a tag or a face) of tasks due today, but I don't want to do a specific search. The idea would be that, within a view of all tasks, I would be able to see at a glance which were due today. Does that make sense? I'm not aware of any such functionality. One solution, I suppose, would be to use org-map-entries and a custom function to add a tag to all entries due today. But adding the tags with org-map-entries would likely be just as slow as a search, so there may not be much point. (info (org) Using the mapping API) On Fri, Apr 23, 2010 at 6:54 PM, Matt Lundin m...@imapmail.org wrote: C-c / m DEADLINE=today [RET] Might I ask why the sparse tree search above or a simple agenda view of deadlines is inadequate? The daily agenda provides a nice view of all deadlines, making clear which are due today and which are past due. And with a custom agenda command you can see only those items that are due today: --8---cut here---start-8--- (setq org-agenda-custom-commands '((d Due today agenda ((org-agenda-entry-types '(:deadline)) (org-deadline-warning-days 0) --8---cut here---end---8--- Best, Matt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] org-mime - issues and remarks
David Maus dm...@ictsoc.de writes: At Mon, 26 Apr 2010 10:04:12 -0600, Eric Schulte wrote: David Maus dm...@ictsoc.de writes: While skimming the source code of org-mime I noticed two severe issues with regards to the MIME specifications: - when creating an attachment for a image org-mime (still) uses the file extension as MIME media subtype for Gnus messages. This not in compliance with RFC 2046. As mentioned before org-mime should/could use the function to determine MIME media type of message-mode and mime-edit-mode respectively. For SEMI the function is `mime-find-file-type', called with the file name as argument and returns a list whose first element is a string with MIME media type and second element is MIME media subtype. Alright, once I find the appropriate similar function in mml/gnus I will make this change. Well, I tried to change it for SEMI but this would require a complete rewrite of `org-mime-replace-images' because `mime-find-file-type' modifies the match-data and the `replace-regexp-in-string' get's confused (i.e.: throws an error). I'll see if I can come up with something w/o rewriting to much. The `save-match-data' macro should fix this. Furthermore there are some minor glitches: - the filename parameter is only defined for the content-disposition header field; because images are attachments they can/should be easily send with content-disposition: attachment; filename=filename For SEMI (replace _ by -): __[[type/subtype content-disposition: attachment; filename=filename][base64]] could you expand upon this point, what's the problem? Hm. I noticed that in the test mail of Eric Fraga[1] images where attached as: , | Content-Type: application/octet-stream; type=image/png | Content-ID: _home_ucecesf_s_test_mip.png; filename=/home/ucecesf/s/test/mip.png | Content-Transfer-Encoding: base64 ` I.e. with the 'filename=' parameter in the Content-ID MIME header field. That wouldn't be correct or, say, not entirely correct because the filename option is only defined in a Content-Disposition MIME header field. So, the old story: It's out of the scope of MIME so you don't know what receiving clients will do. Anyway, org-mime currently does not put a filename parameter at all so what's only left is to send attached images with SEMI is Disposition: attachment like Gnus does. The difference: The Content-Disposition MIME header field contains an optional hint for the receiving MUA what to do with attached files. - 'inline' :: Show attachment without user interaction. - 'attachment' :: Show attachment only with explicit user interaction. For the attached images we don't want them to be shown without user interaction but rendered in the html markup. Sending them with Disposition: inline could result in a MUA showing the images inside the html markup and again maybe at the bottom of the message. Alright, it shouldn't be hard to add the attachment content disposition to the attachment strings. And if I'm reading you correctly we should also place a filename parameter in the Content disposition header? - org-mime uses `reporter-compose-outgoing' to open a new message draft. This is not a could solution because (a) org-mine does not want to send a bug report and (b) would depend on reporter.el without necessity. I don't think this is a problem, I think reporter.el is the best approach here. Yes, I admit this is somewhat pedantic and hypothetical: If you depend on reporter that you should say so (require 'reporter) and you will depend on this particular implementation of `reporter-compose-outgoing'. As soon as this function does something else or something more, strange things might happen. It's like taking a detour: When we prepare the message draft we already know which functions are required depending on `org-mime-library'. The (require 'reporter) string is present in org-mime.el, so I think we're all set here. Thanks -- Eric HTH -- David [1] mid:87hbndq0ym.wl%ucec...@ucl.ac.uk -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Limited #+INCLUDE ?
On Apr 27, 2010, at 9:19 PM, Dan Davison wrote: Samuel Wales samolog...@gmail.com writes: Another way to look at it is that this is an annotation mechanism. It can be used for any type of file or buffer. This would include text, websites (i.e. pointing to and annotating documents on the web), dired, source code, org files, html source, etc. Modifying existing link syntax will be difficult, especially because there might be additional features we need a year or two from now. For maximum flexibility and simplicity, this might be a good first use of extensible syntax. Hi Samuel, I'm not quite clear what you're referring to when you say this in the above sentences. Also, when you say extensible syntax, are you referring to the existing link syntax, or to a proposed extension? Samuel wrote about this a year ago. http://article.gmane.org/gmane.emacs.orgmode/11896/match=wales+extensible - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Is this the best place for noob questions too?
I notice that you guys all seem to be VERY MUCH experts in orgmode. . . my questions are all very . . urm . . RTFM'ish, or just noobish. Should I be posting them somewhere else? I'm still incorporating org-mode into my life, and making many mistakes . . . but, I love the simplicity. I'm also loving having emacs back in my life too. Last night, I remotely edited some files on my web server. I've been doing that for a while with sshfs, but, I forgot how seamless you can do it with emacs. . . pretty much deprecated sshfs for me (in the way I use it -- I'm either editing a lot of stuff, or I ssh over, or I rsync -- I had been using sshfs for the editing, and now no longer need to!) Anyway, thanks for the answers so far, and thanks for the new ones that will surely come when I get confused again. I think my next goal is to come up with some way to use multiple files to help my organizaition . . and somehow link them together. (Don't tell me . . still reading the fine manual!) -Dave ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Gmane readers - please subscribe
Sebastian Rose sebastian_r...@gmx.de writes: OK - there _must_ be a missunderstanding... Quite probably. But I don't wish to make further noise about a topic most here likely don't care much about, so I will try to make this my last message in this thread unless new information comes to light. We all post via reply all to support unsubscribed users. They (you?) couldn't discuss in realtime otherwise. In fact, many people in this thread have *not* done that, and I've read every message sent to the forum just fine. Gmane allows an NNTP interface to the forum; that's pretty much the point for me. If you are sending an extra copy to me specifically, please don't; it doesn't help. As for the many suggestions to set up authentication tokens that lie dormant: I have explained my position on proliferation of authentication tokens, and some people have understood. That's good enough for now. Let's get back to Org-mode discussions :-) -- \ “Dad always thought laughter was the best medicine, which I | `\guess is why several of us died of tuberculosis.” —Jack Handey | _o__) | Ben Finney ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Is this the best place for noob questions too?
On Wednesday 28 April 2010 10:00 am, David Frascone wrote: I notice that you guys all seem to be VERY MUCH experts in orgmode. . . my questions are all very . . urm . . RTFM'ish, or just noobish. Should I be posting them somewhere else? I'm still incorporating org-mode into my life, and making many mistakes . . . but, I love the simplicity. I'm also loving having emacs back in my life too. Last night, I remotely edited some files on my web server. I've been doing that for a while with sshfs, but, I forgot how seamless you can do it with emacs. . . pretty much deprecated sshfs for me (in the way I use it -- I'm either editing a lot of stuff, or I ssh over, or I rsync -- I had been using sshfs for the editing, and now no longer need to!) Anyway, thanks for the answers so far, and thanks for the new ones that will surely come when I get confused again. I think my next goal is to come up with some way to use multiple files to help my organizaition . . and somehow link them together. (Don't tell me . . still reading the fine manual!) -Dave As fellow newbie, I sometimes wonder myself. This list is high traffic, with much on add-in Org-mode packs, hacks and source bug-fixes. So for me, its still basically the Tutorials and Introductions. Thanks to all involved for those. And the Org-mode Manual of course, which itself is a little dense or daunting - perhaps the key to all. Babel sure looks good or handy, but I'm not there yet. Remember-mode is sure handy. Am still juggling the Agendas and Tags, almost publishing. Nice to hear from another newbie. Will keep plugging away. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Is this the best place for noob questions too?
You can also join #org-mode on freenode On Tue, Apr 27, 2010 at 7:31 PM, Adam ah...@ihug.co.nz wrote: On Wednesday 28 April 2010 10:00 am, David Frascone wrote: I notice that you guys all seem to be VERY MUCH experts in orgmode. . . my questions are all very . . urm . . RTFM'ish, or just noobish. Should I be posting them somewhere else? I'm still incorporating org-mode into my life, and making many mistakes . . . but, I love the simplicity. I'm also loving having emacs back in my life too. Last night, I remotely edited some files on my web server. I've been doing that for a while with sshfs, but, I forgot how seamless you can do it with emacs. . . pretty much deprecated sshfs for me (in the way I use it -- I'm either editing a lot of stuff, or I ssh over, or I rsync -- I had been using sshfs for the editing, and now no longer need to!) Anyway, thanks for the answers so far, and thanks for the new ones that will surely come when I get confused again. I think my next goal is to come up with some way to use multiple files to help my organizaition . . and somehow link them together. (Don't tell me . . still reading the fine manual!) -Dave As fellow newbie, I sometimes wonder myself. This list is high traffic, with much on add-in Org-mode packs, hacks and source bug-fixes. So for me, its still basically the Tutorials and Introductions. Thanks to all involved for those. And the Org-mode Manual of course, which itself is a little dense or daunting - perhaps the key to all. Babel sure looks good or handy, but I'm not there yet. Remember-mode is sure handy. Am still juggling the Agendas and Tags, almost publishing. Nice to hear from another newbie. Will keep plugging away. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Turning on TOC export of timestamps for headlines
I can't seem to get timestampts to export to HTML as part of the TOC when they're in a headline, e.g. the following org-mode headline ** Foo 2010-04-04 Exports to the table of contents as just Foo, is there anyway to get the timestamp listed also? I've tried setting a timestamp:t option for my #+OPTIONS: but it doesn't seem to work. Any help appreciated. R. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Limited #+INCLUDE ?
On 4/26/2010 7:19 PM, Dan Davison wrote: Mark Elstonm_els...@comcast.net writes: Dan, The use of line numbers seems a little error prone since line numbers can change dramatically by simply editing the file. If you edit one section of a file, even if you update the line numbers for that section, you will need to search out all the *other* links to sections in that file and update them as well as they will become stale. And, since it will be possible to have multiple org files with links into a single source file, this will be a *very* difficult thing to manage. Hi Mark, Your idea about regexps sounds promising, though. My current thought is that Emacs bookmarks might be the technology to use here. They seem to be designed for this task (saving a reference to a location in a file which is robust to mild file alteration), they are almost 20 years old, and there is already org-bookmarks.el in contrib by Tokuya Kameshima[1]. I haven't tried this so I don't know how resilient it is to changes in the target file. (info (emacs) Bookmarks) You could define 'markers' in comments delimiting the relevant sections of code and org could search these out easily enough. My hope was to avoid forcing the target files to receive extra Org-related content. E.g. suppose that the target files are a collaborative project involving non-Org users that is under version control; one wouldn't want to commit those special tags, and one wouldn't particularly want to have to filter them out them when making commits. It's the non-org users that would, of course, be the 'problem', though. They are the ones likely to make non-mild edits and not update links. In a collaborative project you will likely always be trying to keep your links up-to-date without some kind of marker in the code. Dan [1] I haven't looked into this properly, but to avoid staleness one possibility would be to modify Tokuya's links to actually include the lisp form defining the bookmark (i.e. the entry in bookmark-alist) in the non-visible portion of the link (?). My proposed range links would employ two bookmarks. Mark ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [BUG] latex superscript and documentation bugs
Org:
x^{(0)}
becomes [note missing parenthesis]
LaTeX:
x$^{\mathrm{(0}}$
(Emacs 24 with Org 6.35i and also with current Org-mode HEAD)
Also, two possible documentation bugs:
1
=
http://orgmode.org/manual/Images-and-tables.html#Images-and-tables
says
You can use the following lines somewhere before the table to assign
a caption and a label for cross references, and in the text you can
refer to the object with \ref{tab:basic-data}:
I think that is a LaTeX-specific comment in a non-LaTeX specific manual
section? Should it say and if exporting to LaTeX, in the text you can
refer to the object...?
2
==
In the docstring for org-export-latex-classes it says
So a header like
\documentclass{article}
[NO-DEFAULT-PACKAGES]
[EXTRA]
\providecommand{\alert}[1]{\textbf{#1}}
[PACKAGES]
will omit the default packages,
I wonder whether it would be better to show the double backslashes (\\)
explicitly, seeing as the user will need to escape them in this way, or
at least to warn the reader.
Dan
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [BUG] fill-paragraph on commented line
I can see from the archives that fill-paragraph is a bit of a headache, but, still, I have a couple of queries... Firstly, with point on the # character below, M-q wraps the long line below, rather than the commented line, which is suprising. --8---cut here---start-8--- # long line here long line here long line here long line here long line here long line here long line here long line here long line here long line here second long line here second long line here second long line here second long line here second long line here second long line here second long line here second long line here --8---cut here---end---8--- Also, would you mind reminding me what the intended behaviour is for M-q on list items? If I have - item1 stuff here stuff here stuff here stuff here stuff here stuff here and do M-q, ideally I'd like it not to put the stuff here line onto the item1 line. Is that desirable but hard / not desirable / supposed to be happening? Thanks, Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] org-html link building diff
The changes are essentially made and pass my tests now, there's mostly housekeeping now: pull, merge, push. Yes. Send me your name on repo.or.cz and I'll add push for you. Please create your own branch and stay on it. It is Tehom. This is for having a clickable Thumbnail - I am not sure if this is also handled elsewhere. I believe it is. The only difference seems to be that the first builds: : a href=foo/target.htmlimg src=some.jpg/a all by itself and the second builds: : img src=some.jpg href=foo/target.html thru `org-export-html-format-image'. Only the second handles captions. If the captions etc are the issue, then it should all go thru the second. Plus, `org-export-html-format-image' seems to be the right place for image code. It would be bad if changes added to `org-export-html-format-image' didn't take because this other code handled it instead. A few questions: * Encountered while writing tests: When type is file and path is an absolute filename, we do substitutions. Like /foo/unfoo/.././baz becomes /foo/baz. But we don't do them when path is relative. Why not? Is that just because we'd then need to make it relative again which is more code, or is there some other reason? * Also found in the course of testing: id: links cause errors when buffer is not associated with a file. This can happen when the arg body-only is passed. * Punt id links in that case? * Do them but avoid the filename relativizing step? * How do you feel about url-parse? It's bundled with emacs, builds and destructures urls. IMO we're not at the stage where it provides more help than the extra work it requires yet. Tom Breton (Tehom) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
