octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #46795] dbstop lacks much Matlab functionality


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #46795] dbstop lacks much Matlab functionality
Date: Sat, 23 Jan 2016 13:55:21 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38

Follow-up Comment #38, bug #46795 (project octave):

@Lachlan

(please correct me if I'm wrong)
If I translate what you describe as 
- "CLI" into "terminal" (or "terminal pane"),
- "GUI" into "editor pane",
and what I describe as:
- "GUI" into "any GUI pane, terminal inclusive"
- "CLI" into "octave-cli executable (!= GUI)",

... it turns out in hindsight we've been talking about the same things all
along ...

I might have been a little confused here because on Windows the terminal pane
(AFAIK originally based on some KDE terminal) is quite different from the
octave-cli window (based on Windows' cm32.exe) and behaves quite differently
in several aspects. So differences between "CLI" and "GUI" rang the wrong bell
here ...

Indeed everything works as advertised. I've tried all the updated patches
incl. the one from bug #46931

As to the help text:
*Conditions containing quotes (", ') and comment characters (#, %) should be
enclosed in extra (different) quotes if entered in the terminal. (This does
not apply to conditions entered in the editor's context menu.)*
Would that be OK?

As to the solutions:

- Considering that many many Octave users still prefer the CLI (no GUI), (4)
and (5) seem less well applicable.

- I'd prefer (1) for the time being & consult JWE as to (3).

- As to (2), an error message along the lines of 
"Did you forget double-quoting debug conditions containing quotes or comment
characters?" or just 
"Did you forget double-quoting debug conditions containing ", ', # or % ?", 
maybe after the parser's complaints (like "warning: Error evaluating
breakpoint condition:") if those can't be catched, might help?

FWIW, in my own experience error messages in my code started out fairly
roughly ; only after several comments, questions and sometimes even bug
reports from users and revisiting code by myself years later they got more
to-the-point. That's inevitable because programmers just cannot imagine all
use cases that ordinary users may come up with. So on the one hand no need to
get a perfect error message right now, OTOH we just do the best we can at this
moment.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?46795>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]