bugGNU Octave - Bugs: bug #36744, backslash before underscore on...

 
 

bug #36744: backslash before underscore on plots

Submitter:  Sergei Steshenko <sergstesh>
Submitted:  Thu 28 Jun 2012 06:18:56 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  bpabbott
Originator Name:  Open/Closed:  * Closed
Release:  * 3.6.2 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 08 May 2014 03:50:51 AM UTC, comment #10: 

Cool, thanks for testing.  I pushed the changeset here (http://hg.savannah.gnu.org/hgweb/octave/rev/8b90d4be063b).

Rik <rik5>
Group administrator
Thu 08 May 2014 02:22:23 AM UTC, comment #9: 

Rik, this code looks like something I wrote.  My impression was that ...


xlabel ({"foo_bar", "hello_world"}, "interpreter", "none")


... would be a good test. Your patch rendered the correct result.

I also tried ...


xlabel ("foo_bar", "interpreter", "none")



xlabel ({"foo_bar", "hello_world"}, "interpreter", "tex")



xlabel ("foo_bar", "interpreter", "tex")


These also rendered correctly.  Looks good to push.

Ben Abbott <bpabbott>
Group Member
Thu 08 May 2014 01:31:10 AM UTC, comment #8: 

I'm attaching a patch against the stable branch that works for me.  The gnuplot routines are awfully complicated so if others can test it that would be useful.  If it passes I will check it in.

(file #31332)

Rik <rik5>
Group administrator
Wed 07 May 2014 11:01:01 PM UTC, comment #7: 

I understand your annoyance at duplicate bug reports, entirely justified.  But please accept responsibility for your own contributory actions in causing them to occur. As I indicated, a conscientious attempt was made to re-open the earlier report, but found it impossible to do so (as you confirm.) And previous admin responses to other (unrelated) tickets had indicated that filing comments in closed tickets was not useful. That doesn't leave many options other than filing a new report referencing the old one, which is  what I did.

Regarding the bug: Attached is another example that demonstrates that this problem occurs not only with text() but with xlabel() as well.

It also demonstrates what may or may not be a related issue: That the 'interpreter' property does not seem to be getting inherited properly by graphical objects created subsequent to


set(0, 'DefaultTextInterpreter', 'none')


That issue was discussed in Ticket #40064, so I attached the example script to that ticket as well, since it illustrates both problems.

(file #31331)

Glenn Golden <grepfor>
Sun 04 May 2014 05:31:49 PM UTC, comment #6: 

Let's try to keep the comments pertinent to the bug report.

If we have hurt your feelings, I apologise. It seems like it was just a misunderstanding.

In the future, please refrain from opening duplicate bug reports. That clutters our bug tracker with noise and creates extra work as we track down the duplicates.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sun 04 May 2014 01:15:47 PM UTC, comment #5: 


You don't need the bug report to be open in order to comment on it.


I'm aware of that. Several months ago I filed a comment reporting a broken link in a closed bug report (#40064) and was told "this bug report has been closed for several months." My interpretation of that sentence was that it is not a good idea to file comments on closed bug reports.

+verbatim-
...so if you want to reopen a bug report, just start talking on it again.
-verbatim-

It seems that what you mean is actually something like this: "If you would like a closed bug report to be considerd for re-opening by the administrators, then file comments on the closed report. If the admins decide that it should be reopened based on your new comments, then they will do so".

That's very different from the curt, "Then reopen the old bug report, don't start a new one."

The word "reopen" means "to open again". It does not mean "to add comments to a closed report requesting that it be re-opened by the admins". If a non-admin user can't 'reopen' a bug report, then telling him snarkily and explicitly to 'reopen' it is inaccurate, borderline rude, and basicallly asking for misunderstanding and irritation.

A better alternative might be a polite response such as, "In the future, when a closed bug has re-appeared, please add new comments to the closed bug report requesting it be reopened, rather than filing a new one."




If you would like to document this, you can do it on wiki.octave.org


At present, my contribution level is limited to bug reports.

Glenn Golden <grepfor>
Sun 04 May 2014 12:36:32 AM UTC, comment #4: 

You don't need the bug report to be open in order to comment on it. Only project admins can open and close bug reports, so if you want to reopen a bug report, just start talking on it again.

If you would like to document this, you can do it on wiki.octave.org

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sat 03 May 2014 10:36:25 PM UTC, comment #3: 


> Follow-up Comment #4: (in bug #42271)
>
> Then reopen the old bug report, don't start a new one.
>



Before filing the new report, I attempted to figure out how to change the status of the existing report -- this one, #36744 --from 'closed' to 'open'.  I was unable to find any means to do so, though perhaps I missed it. The "Open/Closed" field  does not appear to be editable, and none of the docs in the "Site Help" section (left column) seemed to have any specifics on this either.

What is the appropriate way to go about doing this, and where is it documented?


Glenn Golden <grepfor>
Sat 03 May 2014 09:35:56 PM UTC, comment #2: 

Reopening this bug report, which seems to have returned.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Fri 29 Jun 2012 09:22:16 PM UTC, comment #1: 

The missing semicolon problem had been fixed before, but regressed.

http://hg.savannah.gnu.org/hgweb/octave/rev/351ca094580b

The backslash problem has already been fixed.

http://hg.savannah.gnu.org/hgweb/octave/rev/1f922eedf9ce

Ben Abbott <bpabbott>
Group Member
Thu 28 Jun 2012 06:18:56 PM UTC, original submission:  
Sergei Steshenko <sergstesh>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #31332:  gnuplot_backslash.cset added by rik5 (2KiB - application/octet-stream)
file #31331:  ex2.m added by grepfor (2KiB - text/x-objcsrc)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by grepfor (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by jordigh
  • -email is unavailable- added by bpabbott (Updated the item)
  • -email is unavailable- added by sergstesh (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-05-08 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2014-05-08 rik5 Attached File- Added gnuplot_backslash.cset, #31332
        StatusConfirmed Ready For Test
    2014-05-07 grepfor Attached File- Added ex2.m, #31331
    2014-05-03 jordigh StatusFixed Confirmed
        Open/ClosedClosed Open
        Carbon-Copy- Added grepfor
    2014-05-03 jordigh Dependencies- bugs #42271 is dependent
    2012-06-29 bpabbott StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2012-06-29 rik5 Carbon-CopyRemoved 72865 -
    2012-06-29 rik5 Summarybackslash before undescore on plots backslash before underscore on plots
    2012-06-28 bpabbott CategoryPlotting Plotting with gnuplot
        StatusNone Confirmed
        Assigned toNone bpabbott

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code