Re: [O] face-at-point
Uwe Brauer o...@mat.ucm.es writes: The issue is that org-7 shipped its own outline version for org mode called noutline, I don't know why it disappear, so I simply copied noutline into the org-8 directory added a (require 'noutline) to org.el That's because XEmacs's outline.el is now what used to be noutline.el. (It has been for about 3 years.) So you can just require outline.el. -- Regards, Mike
[O] face-at-point (was: serious problems with org-8 under Xemacs-21.5.32)
Nick == Nick Dokos ndo...@gmail.com writes: Uwe Brauer o...@mat.ucm.es writes: Hello You need to set up auto-mode-alist in your init file: (add-to-list 'auto-mode-alist '(\\.org$ . org-mode)) Ok, I did this - I turned on org-mode and received and error I attach. The error is[fn:1]: I am sorry, this is also the fault of gnus-dired-attach Which my default uses this type of attachment, I have to look into it, how to change it on demand. command-execute(org-mode t) execute-extended-command(nil) call-interactively(execute-extended-command) so xemacs found an outline.el that did not define outline-previous-heading. Check which outline.el xemacs finds with M-x locate-library RET outline RET. It's probably a compiled file, but the corresponding outline.el should be in the same directory, or you might need to get a source package with the xemacs .el files to find it. Check what version it is, compare it with the emacs version, check whether it includes outline-previous-heading (probably not, hence the error). The issue is that org-7 shipped its own outline version for org mode called noutline, I don't know why it disappear, so I simply copied noutline into the org-8 directory added a (require 'noutline) to org.el And run make again, now org, works, at least partially. I will CC to xemacs-beta about the outline.el version, because the one shipped in the pkg xemacs-base is very old. No I better open a new thread there. - I tried to use org-preview-latex-fragment and received a different error (also attached) The error here: Debugger entered--Lisp error: (void-function face-at-point) face-at-point() Presumably xemacs does not have face-at-point. Yes and this is a problem. I presume this function is new in GNU emacs 24? - I tried to use org-submit-bug-report and received third error. Debugger entered--Lisp error: (void-function call-process-shell-command) call-process-shell-command(command nil nil nil -v x11idle) and it does not seem to have call-process-shell-command. This is a thin wrapper around call-process (which xemacs should have), so this should be easy to port. Ok I ask in xemacs-beta Thanks for your help. Uwe smime.p7s Description: S/MIME cryptographic signature
Re: [O] face-at-point
Uwe Brauer o...@mat.ucm.es writes: The error is[fn:1]: I am sorry, this is also the fault of gnus-dired-attach Which by default uses this type of attachment, I have to look into it, how to change it on demand. gnus-dired-attach uses mm-default-file-encoding to figure things out. That in turn calls mailcap-extension-to-mime which uses your mailcap file (see the mailcap man page) and the file extension. If you give your backtrace files a .txt extension, chances are good that they will end up with mime type text/plain. Evaluate this to make sure: --8---cut here---start-8--- (mailcap-extension-to-mime txt) text/plain --8---cut here---end---8--- Or look through your mailcap file and find a mime-type that is appropriate and use whatever extension it needs. -- Nick
Re: [O] face-at-point
Nick Dokos ndo...@gmail.com writes: Uwe Brauer o...@mat.ucm.es writes: The error is[fn:1]: I am sorry, this is also the fault of gnus-dired-attach Which by default uses this type of attachment, I have to look into it, how to change it on demand. gnus-dired-attach uses mm-default-file-encoding to figure things out. That in turn calls mailcap-extension-to-mime which uses your mailcap file (see the mailcap man page) and the file extension. If you give your backtrace files a .txt extension, chances are good that they will end up with mime type text/plain. Evaluate this to make sure: (mailcap-extension-to-mime txt) text/plain Or look through your mailcap file and find a mime-type that is appropriate and use whatever extension it needs. Sorry - /etc/mime.types is the file that maps extensions to mime-types, not mailcap. -- Nick
Re: [O] face-at-point
Nick == Nick Dokos ndo...@gmail.com writes: Uwe Brauer o...@mat.ucm.es writes: The error is[fn:1]: I am sorry, this is also the fault of gnus-dired-attach Which by default uses this type of attachment, I have to look into it, how to change it on demand. gnus-dired-attach uses mm-default-file-encoding to figure things out. I tried to generalize this function so that it optionally takes the type as an argument. Too complicated. That in turn calls mailcap-extension-to-mime which uses your mailcap file (see the mailcap man page) and the file extension. If you give your backtrace files a .txt extension, chances are good that they will end up with mime type text/plain. Evaluate this to make sure: right, or even save it as .el would do the trick, smime.p7s Description: S/MIME cryptographic signature
Re: [O] face-at-point
Uwe Brauer o...@mat.ucm.es writes: Nick == Nick Dokos ndo...@gmail.com writes: Uwe Brauer o...@mat.ucm.es writes: The error is[fn:1]: I am sorry, this is also the fault of gnus-dired-attach Which by default uses this type of attachment, I have to look into it, how to change it on demand. gnus-dired-attach uses mm-default-file-encoding to figure things out. I tried to generalize this function so that it optionally takes the type as an argument. Too complicated. Eric Fraga has been prolific in providing solutions to these problems today. In addition to the client side solution (Use v instead of t) which solves the problem on the recipient's side, he provided another solution (which I have used in the past, but I forgot all about it until I saw Eric's reply to your question in the gnus mailing list) that solves the problem on the sender's side: let gnus-dired-attach default to whatever it bloody well pleases - the attachment cookie it inserts in the mail you are composing is just text (until you hit C-c C-c and then it becomes a real attachment), so if the type is not to your liking, you can go ahead and edit it at will (I've stripped out parts of the cookie, so it won't be mistaken as a real attachment - I'm not sure how to quote it so that it won't be recognized): ... type=application/octet-stream filename=~/Desktop/foo disposition=attachment description=Hunoz to ... type=text/plain filename=~/Desktop/foo disposition=attachment description=Hunoz Another instance of the Your life in plain text principle. I thought I'd post a note with Eric's solution here, just to close the loop all the way. Here is a reference to his reply: http://thread.gmane.org/gmane.emacs.gnus.general/83319/focus=83320 Thanks, Eric! -- Nick
Re: [O] face-at-point
Nick Dokos ndo...@gmail.com writes: Eric Fraga has been prolific in providing solutions to these problems today. Can you tell I didn't feel like doing any more work at some point in the day (after an 8 hour meeting...)? ;-) Thanks, Eric! You're very welcome! Now off to have a glass of wine and to read a novel. Have a great weekend everybody (on this and other lists)! -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.3-239-gd316ec
Re: [O] face-at-point
Nick == Nick Dokos ndo...@gmail.com writes: Uwe Brauer o...@mat.ucm.es writes: Eric Fraga has been prolific in providing solutions to these problems today. In addition to the client side solution (Use v instead of t) which solves the problem on the recipient's side, he provided another solution (which I have used in the past, but I forgot all about it until I saw Eric's reply to your question in the gnus mailing list) that solves the problem on the sender's side: let gnus-dired-attach default to whatever it bloody well pleases - the attachment cookie it inserts in the mail you are composing is just text (until you hit C-c C-c and then it becomes a real attachment), so if the type is not to your liking, you can go ahead and edit it at will (I've stripped out parts of the cookie, so it won't be mistaken as a real attachment - I'm not sure how to quote it so that it won't be recognized): ... type=application/octet-stream filename=~/Desktop/foo disposition=attachment description=Hunoz to ... type=text/plain filename=~/Desktop/foo disposition=attachment description=Hunoz yes I have seen his answer, problem with this approach: you have to know by heart which is hte correct type. I never can remember whether it is text/plain or plain/text mml-attach-file gives you a list of options. Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
Re: [O] face-at-point
Uwe Brauer o...@mat.ucm.es writes: Nick == Nick Dokos ndo...@gmail.com writes: Uwe Brauer o...@mat.ucm.es writes: Eric Fraga has been prolific in providing solutions to these problems today. In addition to the client side solution (Use v instead of t) which solves the problem on the recipient's side, he provided another solution (which I have used in the past, but I forgot all about it until I saw Eric's reply to your question in the gnus mailing list) that solves the problem on the sender's side: let gnus-dired-attach default to whatever it bloody well pleases - the attachment cookie it inserts in the mail you are composing is just text (until you hit C-c C-c and then it becomes a real attachment), so if the type is not to your liking, you can go ahead and edit it at will (I've stripped out parts of the cookie, so it won't be mistaken as a real attachment - I'm not sure how to quote it so that it won't be recognized): ... type=application/octet-stream filename=~/Desktop/foo disposition=attachment description=Hunoz to ... type=text/plain filename=~/Desktop/foo disposition=attachment description=Hunoz yes I have seen his answer, problem with this approach: you have to know by heart which is hte correct type. I never can remember whether it is text/plain or plain/text mml-attach-file gives you a list of options. Ideally, the /etc/mime.types mapping will take care of things automatically. But this is a last-ditch opportunity to get it right. You can always M-x grep RET plain /etc/mime.types RET (or jpg, or jpeg, or pdf, or whatever) to verify the correct form. Or put it in a function and bind it to a key so you don't have to remember the name of the file. OTOH, if you send it out wrong, I now know how to open the attachment correctly using Eric's other solution - the problem has almost vanished and life is good... -- Nick
