vc-hg modeline changed.

vc-hg modeline changed.

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]


Hi

I just upgraded 25.5.1  via git pull and recompiling.

Then I noted (to my horror (personal opinion) that the behavior of
hg-modeline was changed.

The relevant log entry is this:

commit de76a167dc09dc695a5acebabb7ab354a6bf556e
Author: Daniel Colascione <dancol@dancol.org>
Date:   Mon Feb 8 10:52:54 2016 -0800

    Performance improvements for vc-hg
    
    Teach vc-hg how to read some Mercurial internal data structures,
    allowing us to avoid the need to run hg status -A, which is very slow
    for large repositories.  Fall back to running hg if anything looks
    funny.  vc-hg now puts the _working directory_ revision in the
    modeline instead of the file revision, which greatly improves
    performance and which allows us to again skip running hg in the case
    that we have an active bookmark.
    
Very well, now per default hg displays the tag (if there is any) of the
repo.

I wanted the old behavior and I thought I just set 
 vc-hg-use-file-version-for-mode-line-version to t.

But then HG-hash is displayed not HG-rev.
I don't want to start a flame war about the usefulness of the local rev number,
but for me it is *very* useful.

Please tell me how to obtain the old behavior.

I attach 3 screenshots:
The old one, the new one with the varible set to nil, and then to t.

regards

Uwe Brauer 



[-- Attachment #2: hg-modeline-hash.png --]
[-- Type: image/png, Size: 86715 bytes --]

[-- Attachment #3: hg-modeline-tag.png --]
[-- Type: image/png, Size: 86223 bytes --]

[-- Attachment #4: hg-modeline-rev.png --]
[-- Type: image/png, Size: 87842 bytes --]

SOLVED (was: vc-hg modeline changed.)

[Uwe Brauer]

>>> "Uwe" == Uwe Brauer <oub@mat.ucm.es> writes:

   > Hi

   > I just upgraded 25.5.1  via git pull and recompiling.

   > Then I noted (to my horror (personal opinion) that the behavior of
   > hg-modeline was changed.

I was told my Daniel to try

 (setq vc-hg-symbolic-revision-styles '("{rev}"))

(Or the relevant customize-option)

Which solved my problem.

I suggest to change/add the docstring accordingly, because the new
behavior is a radical change.

I could provide a 'patch' for that[1], but not sure about the structure of
that patch (which git diff option to use, to whom to send that patch
etc).
I will ask that in  a different message.


Uwe Brauer


Footnotes: 
[1]  3 lines of text which would not require to sign the  FSF copyright papers.

Re: SOLVED (was: vc-hg modeline changed.)

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

>
> I suggest to change/add the docstring accordingly, because the new

behavior is a radical change.
>
> I could provide a 'patch' for that[1]


That's great!

, but not sure about the structure of
> that patch



(which git diff option to use


- You first need to rebase your local git area to emacs-25 as you are
planning to provide just a documentation patch, (otherwise you would rebase
to the master branch).
- Then git commit the changes in your local area.
- http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE has
instructions on the style of writing commit logs.
- Use git format_patch HEAD~1 to create patch for that last commit.

, to whom to send that patch
>

- You use the same M-x report-emacs-bug to describe the problem you are
solving along with the inline pasted patch you just created.

etc).


While you are at it, you can even initiate the process to finish the
copyright paperwork if you'd like to contribute more in future (why not!
:)); even though you don't need that right now for 3 lines of documentation
patch.

I see that you heavily contribute to matlab-mode.el. Thanks for maintaining
that! And as Stefan Monnier mentioned in an earlier email thread, that
could possibly be integrated into octave-mode.el piece by piece and be part
of Emacs.

Hope this helps.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2640 bytes --]

Re: SOLVED

[Uwe Brauer]

>>> "Kaushal" == Kaushal Modi <kaushal.modi@gmail.com> writes:



    >     , but not sure about the structure of
    >     that patch



    >     (which git diff option to use


    > - You first need to rebase your local git area to emacs-25 as you are
    > planning to provide just a documentation patch, (otherwise you would
    > rebase to the master branch). 

 I am a bit confused now, I cloned originally via

 git clone git://git.savannah.gnu.org/emacs.git

And then ever pulled from it from time to time. That is what?, master or
emacs-25?

    > - Then git commit the changes in your local area. 
    > - http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE has
    > instructions on the style of writing commit logs. 
    > - Use git format_patch HEAD~1 to create patch for that last commit. 

Ok thanks

    >     , to whom to send that patch


    > - You use the same M-x report-emacs-bug to describe the problem you
    > are solving along with the inline pasted patch you just created. 


    >     etc).


    > While you are at it, you can even initiate the process to finish the
    > copyright paperwork if you'd like to contribute more in future (why
    > not! :)); even though you don't need that right now for 3 lines of
    > documentation patch. 

Right, I wanted to wait till I am again in Germany, since I could to it
electronically while I can't while I am in Spain, progress, sigh


    > I see that you heavily contribute to matlab-mode.el. Thanks for
    > maintaining that!

Ah well, I provided some functionality but I think the person who really
contributed heavily to matlab-mode.el is Eric Ludlam, who unfortunately
is too busy to maintain matlab-mode.el, so I just  stepped in.


    > And as Stefan Monnier mentioned in an earlier email
    > thread, that could possibly be integrated into octave-mode.el piece
    > by piece and be part of Emacs. 

Ah well there are two problems with that:

    -  a technical one. The real difference between these two packages
       IMHO is their shell. The relevant matlab code was written over a
       very long period of time (starting in 91), is very matlab
       specific and looks very complicated to me. I am not really sure
       that anyone besides Eric understands it.

    -  a copyright issue. I did not discuss this in detail on this list,
       but RMS asked me why the code could not be in ELPA instead of
       being in MELPA and the reason is that MathWorks has some
       copyright over some parts of the code and it is very very
       unlikely that they will transfer that copyright to the FSF. The
       code is under GPL2+ though. 


    > Hope this helps. 
    > --

Yes it did thanks.

Uwe 

Re: SOLVED

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

>
>  I am a bit confused now, I cloned originally via
>
>  git clone git://git.savannah.gnu.org/emacs.git
>
> And then ever pulled from it from time to time. That is what?, master or
> emacs-25?
>

By default the origin/master will be cloned.

I use the below to FORCE update to emacs-25

                                 git fetch --all
                                 git checkout origin/emacs-25
                                 git reset --hard origin/emacs-25

Right, I wanted to wait till I am again in Germany, since I could to it
> electronically while I can't while I am in Spain, progress, sigh
>

Cool!

Ah well, I provided some functionality but I think the person who really
> contributed heavily to matlab-mode.el is Eric Ludlam, who unfortunately
> is too busy to maintain matlab-mode.el, so I just  stepped in.
>

Thanks though for keeping the maintenance alive.

Ah well there are two problems with that:
>
>     -  a technical one. The real difference between these two packages
>        IMHO is their shell. The relevant matlab code was written over a
>        very long period of time (starting in 91), is very matlab
>        specific and looks very complicated to me. I am not really sure
>        that anyone besides Eric understands it.
>
>     -  a copyright issue. I did not discuss this in detail on this list,
>        but RMS asked me why the code could not be in ELPA instead of
>        being in MELPA and the reason is that MathWorks has some
>        copyright over some parts of the code and it is very very
>        unlikely that they will transfer that copyright to the FSF. The
>        code is under GPL2+ though.


Understood. matlab-mode.el was just an example. I used to express that once
you have the copyright paperwork, it's much easier to contribute to Emacs
:) But it's great that you are already looking into it.

-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2921 bytes --]

Re: SOLVED

[Andreas Schwab]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> I use the below to FORCE update to emacs-25
>
>                                  git fetch --all
>                                  git checkout origin/emacs-25

You should use "git checkout emacs-25".

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: SOLVED

[Uwe Brauer]

   > That's great! 


   >     , but not sure about the structure of
   >     that patch



   >     (which git diff option to use


   > - You first need to rebase your local git area to emacs-25 as you are
   > planning to provide just a documentation patch, (otherwise you would
   > rebase to the master branch). 
   > - Then git commit the changes in your local area. 
   > - http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE has
   > instructions on the style of writing commit logs. 
   > - Use git format_patch HEAD~1 to create patch for that last commit. 


   >     , to whom to send that patch


   > - You use the same M-x report-emacs-bug to describe the problem you
   > are solving along with the inline pasted patch you just created. 


   >     etc).


   > While you are at it, you can even initiate the process to finish the
   > copyright paperwork if you'd like to contribute more in future (why
   > not! :)); even though you don't need that right now for 3 lines of
   > documentation patch. 

   > I see that you heavily contribute to matlab-mode.el. Thanks for
   > maintaining that! And as Stefan Monnier mentioned in an earlier email
   > thread, that could possibly be integrated into octave-mode.el piece
   > by piece and be part of Emacs. 

   > Hope this helps. 
   > --

BTW, so the manual is a bit outdated and maybe it should be upgraded,
what do you think?.....

BTW which MUA are you using, because I have problems (using gnus) to
separate your response from my text (your are not the first one though)
the quotations with > seems flawed.

Re: SOLVED

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Thu, 05 May 2016 20:12:36 +0000
> 
> BTW, so the manual is a bit outdated and maybe it should be upgraded,
> what do you think?.....

That section of the manual is written for casual contributors.  The
next section, "Contributing to Emacs Development", mentions the file
CONTRIBUTE, which provides the details for more frequent contributors.

Re: SOLVED

[Uwe Brauer]

>>> "Kaushal" == Kaushal Modi <kaushal.modi@gmail.com> writes:

   >     I suggest to change/add the docstring accordingly, because the
   >     new

   >     behavior is a radical change.
   
   >     I could provide a 'patch' for that[1]


   > That's great! 


   >     , but not sure about the structure of

   > - You first need to rebase your local git area to emacs-25 as you are
   > planning to provide just a documentation patch, (otherwise you would
   > rebase to the master branch). 
   > - Then git commit the changes in your local area. 
   > - http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE has
   > instructions on the style of writing commit logs. 
   > - Use git format_patch HEAD~1 to create patch for that last commit. 

I just followed your instructions of your other mail to rebase to
emacs-25, but Daniels changes are not there.

His changes seem only to be in emacs-master. (I am sorry I am not very
familiar with git, for my personal stuff I use hg and I use even the
git-hg plugin to maintain matlab, but I don't dare to do that for
emacs...)

Re: SOLVED

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Hi Uwe,

I am using Google Inbox to write emails. I apologize for the email format
as I don't know what I can do to fix this. This is what it looks like to me
when I am writing the email: http://i.imgur.com/oYhaTHg.png


> I just followed your instructions of your other mail to rebase to
> emacs-25, but Daniels changes are not there.
>


> His changes seem only to be in emacs-master. (I am sorry I am not very
> familiar with git, for my personal stuff I use hg and I use even the
> git-hg plugin to maintain matlab, but I don't dare to do that for
> emacs...)
>

Sorry for creating this confusion. You are correct; those changes to vc-hg
(
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=de76a167dc09dc695a5acebabb7ab354a6bf556e
)
are only in the master branch. So there is no point sending a patch rebased
to emasc-25. I had incorrectly assumed that your documentation patch could
apply to emacs-25 too.

So just rebase to the master branch using the below.

git fetch --all
git checkout master
git reset --hard origin/master

Then format your patch and send it to bug-gnu-emacs@gnu.org.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1881 bytes --]

Re: SOLVED

[Uwe Brauer]

>>> "Kaushal" == Kaushal Modi <kaushal.modi@gmail.com> writes:

Hi Kaushal


   > Hi Uwe,
   > I am using Google Inbox to write emails. I apologize for the email
   > format as I don't know what I can do to fix this. This is what it
   > looks like to me when I am writing the email: http://i.imgur.com/
   > oYhaTHg.png


I see. I just tried out my google account. The reason for this behavior
is that you use, google rich-text-format (which is not really html it
seems). Be it as it may, if you activate the option plain text for
sending, then the quotes are displayed correctly in gnus.

I will ask in the gnus list  how to deal with that, but may I suggest
for the time being to use plain text format? But maybe I am the only one
who find this confusing....

BTW how to you deal with gmail's top posting style, which I find one of
the most annoying things, since it cannot be changes (as you can say in
Thunderbird).


thanks

Uwe 

Re: SOLVED

[Yuri Khan]

On Fri, May 6, 2016 at 1:53 PM, Uwe Brauer <oub@mat.ucm.es> wrote:

> I see. I just tried out my google account. The reason for this behavior
> is that you use, google rich-text-format (which is not really html it
> seems).

I looked at Kaushal’s message and I do see the <blockquote> element
around quoted text. What else would you ask of a MUA?

> BTW how to you deal with gmail's top posting style, which I find one of
> the most annoying things, since it cannot be changes (as you can say in
> Thunderbird).

I am writing this from gmail. When you hit reply, there is a small
button with an ellipsis at the bottom. When you click it, it expands
into a quoted parent message, whereupon you can trim quotes and add
your own text.

Gmail also lets you switch to plain text, using the dropdown menu
button at the bottom right.

Google Inbox, on the other hand, did not support sending
plain-text-only mail the last time I checked. (FYI Inbox and Gmail are
different products.)

Re: SOLVED

[Uwe Brauer]

>>> "Yuri" == Yuri Khan <yuri.v.khan@gmail.com> writes:

   > On Fri, May 6, 2016 at 1:53 PM, Uwe Brauer <oub@mat.ucm.es> wrote:
   >> I see. I just tried out my google account. The reason for this behavior
   >> is that you use, google rich-text-format (which is not really html it
   >> seems).

   > I looked at Kaushal’s message and I do see the <blockquote> element
   > around quoted text.

Correct, that is why Thunderbird/Seamonkey does display the quotes
correctly, gnus seems not. So it might be a gnus problem, or an error in
my configuration. I had a quick look around (without any statistical
analysis I must add): TB, gnus, and gmail I see most often, plus people
who seem to use Emacs, but it is not clear to me which MUA, like Eli
(most likely rmail). Since I seem to be the only one to complain, maybe my
gnus is badly configured. I asked already in the gnus group.


   > What else would you ask of a MUA?

   >> BTW how to you deal with gmail's top posting style, which I find one of
   >> the most annoying things, since it cannot be changes (as you can say in
   >> Thunderbird).

   > I am writing this from gmail. When you hit reply, there is a small
   > button with an ellipsis at the bottom. When you click it, it expands
   > into a quoted parent message, whereupon you can trim quotes and add
   > your own text.

Ok, this I know, I thought there was some hidden configuration which
would allow you to skip this step.



   > Gmail also lets you switch to plain text, using the dropdown menu
   > button at the bottom right.

   > Google Inbox, on the other hand, did not support sending
   > plain-text-only mail the last time I checked. (FYI Inbox and Gmail are
   > different products.)

Ah, ok thanks for clarifying did not know, (or forgot).


Uwe 

SOLVED II (was: SOLVED)

[Uwe Brauer]

>>> "Yuri" == Yuri Khan <yuri.v.khan@gmail.com> writes:

    > On Fri, May 6, 2016 at 1:53 PM, Uwe Brauer <oub@mat.ucm.es> wrote:
    >> I see. I just tried out my google account. The reason for this behavior
    >> is that you use, google rich-text-format (which is not really html it
    >> seems).

    > I looked at Kaushal’s message and I do see the <blockquote> element
    > around quoted text. What else would you ask of a MUA?

Ok, for some reason I set  mm-discouraged-alternatives  from 
      '("text/html" "text/richtext") to nil, which caused the problem I
      described.

Setting it back resolved the problem. Sorry for the noise.

Uwe

Re: SOLVED

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 633 bytes --]

On 2016-05-06 05:28, Yuri Khan wrote:
>> > I see. I just tried out my google account. The reason for this behavior
>> > is that you use, google rich-text-format (which is not really html it
>> > seems).
> I looked at Kaushal’s message and I do see the <blockquote> element
> around quoted text. What else would you ask of a MUA?

I thing the issue is mostly that GMail includes two copy of each message; one with <blockquote>s, and one that claims to be text-only. The text-only one is a mess. Unless you configure your client to ignore the text-only one and regenerate it from the html one, you see what Uwe was seeing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: SOLVED

[Yuri Khan]

On Fri, May 6, 2016 at 6:10 PM, Clément Pit--Claudel
<clement.pit@gmail.com> wrote:
> On 2016-05-06 05:28, Yuri Khan wrote:
>>> > I see. I just tried out my google account. The reason for this behavior
>>> > is that you use, google rich-text-format (which is not really html it
>>> > seems).
>> I looked at Kaushal’s message and I do see the <blockquote> element
>> around quoted text. What else would you ask of a MUA?
>
> I thing the issue is mostly that GMail includes two copy of each message; one with <blockquote>s, and one that claims to be text-only. The text-only one is a mess. Unless you configure your client to ignore the text-only one and regenerate it from the html one, you see what Uwe was seeing.

No, Gmail sends normal “Content-Type: multipart/alternative” messages,
where the first alternative is text/plain and uses conventional “>”
quoting, and the second alternative is text/html, optionally encoded
as quoted-printable, with <blockquote> quoting. The messages are valid
w.r.t. RFC 2822 and RFC 2045, and the text/html payload is loosely
well-formed HTML5.

I should really look at how Gnus renders (and quotes) HTML mail sometime.

Re: SOLVED

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1445 bytes --]

On 2016-05-06 08:24, Yuri Khan wrote:
> No, Gmail sends normal “Content-Type: multipart/alternative”
> messages, where the first alternative is text/plain and uses
> conventional “>” quoting, and the second alternative is text/html,
> optionally encoded as quoted-printable, with <blockquote> quoting.
> The messages are valid w.r.t. RFC 2822 and RFC 2045, and the
> text/html payload is loosely well-formed HTML5.

I don't think so. When I look at the source of Kaushal's messages, the '>' character is missing on the first line of each quoted section (see for example his message <CAFyQvY0-gMVfOTbCvCm7JUZEf2NaWKkfn-EDk2MSM_WTvJVKQw@mail.gmail.com>). Thus what should be rendered as the following is actually as shown below in the message body:

(Intended rendering, as suggested by the blockquotes in the HTML version:)

    > I suggest to change/add the docstring accordingly, because the new
    > behavior is a radical change.

    > I could provide a 'patch' for that[1]

    That's great!

    > , but not sure about the structure of
    > that patch

(Actual rendering:)

    >
    > I suggest to change/add the docstring accordingly, because the new

    behavior is a radical change.
    >
    > I could provide a 'patch' for that[1]


    That's great!

    , but not sure about the structure of
    > that patch

Or is there an issue with Thunderbird's source rendering?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: SOLVED

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Fri, 6 May 2016 08:32:20 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On 2016-05-06 08:24, Yuri Khan wrote:
> > No, Gmail sends normal “Content-Type: multipart/alternative”
> > messages, where the first alternative is text/plain and uses
> > conventional “>” quoting, and the second alternative is text/html,
> > optionally encoded as quoted-printable, with <blockquote> quoting.
> > The messages are valid w.r.t. RFC 2822 and RFC 2045, and the
> > text/html payload is loosely well-formed HTML5.
> 
> I don't think so. When I look at the source of Kaushal's messages, the '>' character is missing on the first line of each quoted section (see for example his message <CAFyQvY0-gMVfOTbCvCm7JUZEf2NaWKkfn-EDk2MSM_WTvJVKQw@mail.gmail.com>). Thus what should be rendered as the following is actually as shown below in the message body:
> 
> (Intended rendering, as suggested by the blockquotes in the HTML version:)
> 
>     > I suggest to change/add the docstring accordingly, because the new
>     > behavior is a radical change.
> 
>     > I could provide a 'patch' for that[1]
> 
>     That's great!
> 
>     > , but not sure about the structure of
>     > that patch
> 
> (Actual rendering:)
> 
>     >
>     > I suggest to change/add the docstring accordingly, because the new
> 
>     behavior is a radical change.
>     >
>     > I could provide a 'patch' for that[1]
> 
> 
>     That's great!
> 
>     , but not sure about the structure of
>     > that patch
> 
> Or is there an issue with Thunderbird's source rendering?

Is this really relevant to Emacs?  If not, could you take this
discussion elsewhere?

Thanks.

Xemacs: org-preview-latex-fragment, png not readable.

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

Hello

I made some progress in getting the function to work in
Xemacs.


The main problem seemed to be the function 
org-dvipng-color which is called in
org-create-formula-image.

The original formulation was 

(defun org-dvipng-color (attr)
  "Return an rgb color specification for dvipng."
  (apply 'format "rgb %s %s %s"
	 (mapcar 'org-normalize-color
		 (color-values (face-attribute 'default attr
		 nil)))))



Which does not work for Xemacs. Thanks to Julian Bradfield,
the solution seems to be:

(defun org-dvipng-color (attr)
  "Return an rgb color specification for dvipng."
  (apply 'format "rgb %s %s %s"
	 (mapcar 'org-normalize-color
 (color-rgb-components
     (face-property 'default (intern (substring (symbol-name attr) 1)))))))


However the png which were generated where to small to be
readable. I attach one at the end of the message.

So I tried out in GNU Emacs 21.3 to comment out
org-dvipng-color in org-create-formula-image.
org-preview-latex-fragment then still works, so  is not
necessary for generating the pngs.

So I tried to do the same in Xemacs but the formulas in the
png files keep being  too small.

What could be the reason for this behavior?

Uwe Brauer 

The following attachment should be an integral. 

Xemacs:

[-- Attachment #2: test3_7801a85c58c7aabc4553724e826b458ba08dda90.png --]
[-- Type: image/png, Size: 96 bytes --]

[-- Attachment #3: Type: text/plain, Size: 12 bytes --]


Gnu Emacs 

[-- Attachment #4: test_7ceb32811fbcd1322f595ca60dcc47456c20b5fe.png --]
[-- Type: image/png, Size: 268 bytes --]

Solved (was: Xemacs: org-preview-latex-fragment, png not readable.)

[Uwe Brauer]

>> On Sat, 28 Jan 2012 21:20:48 +0100, Uwe Brauer <oub@mat.ucm.es> wrote:



   > Which does not work for Xemacs. Thanks to Julian Bradfield,
   > the solution seems to be:

   > (defun org-dvipng-color (attr)
   >   "Return an rgb color specification for dvipng."
   >   (apply 'format "rgb %s %s %s"
   > 	 (mapcar 'org-normalize-color
   >  (color-rgb-components
   >      (face-property 'default (intern (substring (symbol-name attr) 1)))))))


   > However the png which were generated where to small to be
   > readable. I attach one at the end of the message.

The issue are the options 
in 


call-process "dvipng" nil nil nil

After trying out different configurations, I found out that
the option 
"-D" dpi

Does not work well with Xemacs.


So 
	  (call-process "dvipng" nil nil nil
			"-fg" fg "-bg" bg
;;			"-D" dpi
;;			"-x" scale "-y" scale
			"-T" "tight"
			"-o" pngfile
			dvifile)
is ok, however the back and foreground setting as generated
by org-dvipng-color, even with Julian Bradfield's patch do
not produce very nice results. In my Xemacs setting it is better to
comment them out.

So there are two small changes necessary to make 
org-preview-latex-fragment work in Xemacs. One is the above
change, the other 


(font-height (face-font 'default))
      instead of 
(font-height (get-face-font 'default))

I can send a patch against 7.8.03

Uwe Brauer 

Re: Solved

[Bastien]

Hi Uwe,

Uwe Brauer <oub@mat.ucm.es> writes:

> So there are two small changes necessary to make 
> org-preview-latex-fragment work in Xemacs. One is the above
> change, the other 
>
>
> (font-height (face-font 'default))
>       instead of 
> (font-height (get-face-font 'default))
>
> I can send a patch against 7.8.03

Please do so -- but please make sure the patch adapts current code
to XEmacs without suppressing any feature for GNU Emacs.

Thanks in advance!

-- 
 Bastien

Re: Solved

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Hi Uwe,
> 
> Uwe Brauer <oub@mat.ucm.es> writes:
> 
> > So there are two small changes necessary to make 
> > org-preview-latex-fragment work in Xemacs. One is the above
> > change, the other 
> >
> >
> > (font-height (face-font 'default))
> >       instead of 
> > (font-height (get-face-font 'default))
> >
> > I can send a patch against 7.8.03
> 
> Please do so -- but please make sure the patch adapts current code
> to XEmacs without suppressing any feature for GNU Emacs.
> 
> Thanks in advance!
> 

... and bonus points if you also fix the problems described in

    http://thread.gmane.org/gmane.emacs.orgmode/50584

:-)

Nick