Comments on: setPrompt – Setting the Matlab Desktop prompt

By: Yair Altman

Yair Altman — Wed, 23 Jun 2010 16:18:39 +0000

@Rudolph – thanks.
Re the console, I don’t know. You’re welcome to try and possibly modify the source code. If you find anything useful, please send me

By: Rudolph

Rudolph — Wed, 23 Jun 2010 15:18:11 +0000

I’ve been looking for a decent prompt control/replacement for a *very* long time! This is fantastic!

I do have one question/request. Mostly I run MatLAB in a term (gnome-terminal/konsole/whatever) and not from the MatLAB GUI (matlab -nosplahs -nodesktop).

Would your approach work for modifying the prompt in a console? Maybe something like setPromptCon..?

By: Yair Altman

Yair Altman — Wed, 31 Mar 2010 15:21:04 +0000

@junziyang – yes: you can add the setPrompt command to your startup.m function and it will be used in each Matlab session automatically.

If you don’t have a startup.m file, simply create one in your Matlab startup folder – it’s a simple Matlab script file that contains commands that run automatically whenever Matlab starts in that folder.

By: junziyang

junziyang — Wed, 31 Mar 2010 06:10:09 +0000

Another GREAT work!
Can this function be improved to make the user difined prompt as the default one instead of calling setPrompt to manually set on each MATLAB session?

By: Yair Altman

Yair Altman — Tue, 02 Feb 2010 07:16:17 +0000

@Bassam – you can use a similar approach to setPrompt (you can use setPrompt‘s source code as the baseline) – set the command-window’s CaretUpdateCallback to send the new text to the remote PC and then store the existing text in a persistent variable. Your callback function will look something like this:

function setPromptFcn(jTextArea,eventData)
 
  % Callback reentry-prevention
  persistent inProgress
  if isempty(inProgress)
    inProgress = 1;  %#ok unused
  else
    return;
  end
 
  % Preserve the last-processed text position
  persistent previousPos
  if isempty previousPos,  previousPos=0;  end
 
  % Process new text
  cwText = get(jTextArea,'Text');
 
  % Handle clear-window actions
  if length(cwText) < previousPos
    previousPos=0;
  end
 
  % Send the new text to the remote PC
  sendRemote(cwText(previousPos+1:end));
  previousPos = length(cwText);
 
  % Re-enable additional callback events
  inProgress = [];

By: Bass

Bass — Tue, 02 Feb 2010 03:27:07 +0000

Hey Yair, Great article on setPrompt

I would like to catch everything that will be printed in the command window and be able to send it to a remote PC via udp.

Can you suggest what callbacks/ approach may be useful in doing this?

thanks!

By: Yair Altman

Yair Altman — Tue, 26 Jan 2010 23:20:43 +0000

Update: I have received a report that setPrompt fouls up the Command Window (CW) on Mac platforms. Since the utility's code and the CW is Java-based, I have a feeling that the problems are due to bugs in the Java used on MacOS (there are numerous other problems with Java on Mac that affect Matlab). I can't test this since I have no Mac.Oh well - I guess we're left with using setPrompt on non-Mac platforms.I would love to hear specific details about similar compatibility issues.

By: Yair Altman

Yair Altman — Tue, 26 Jan 2010 08:55:08 +0000

Hi Mike – Since the original post I have discovered two minor edge cases – when clearing the window (clc) and when invoking other windows (e.g., edit). These issues have since been fixed in the posted code as well as on FEX (should be available later today I guess).

The only unsolved issue I have seen is that when selecting desktop text and pasting to the Editor, the prompt is not stripped as it is with the default prompt.

Otherwise, the new prompt appears to work exactly as expected, with copy/paste, selection/F9, tab completion, help popups, history/editing etc. The Editor-Desktop interaction also works exactly as expected (aside from the known issue above).

I haven’t tested thoroughly on non-Windows platforms and/or multiple Matlab releases, but I expect the changes to be minor at worst.

Regarding assumptions, there are two inherent: that the default prompt ends with ‘>> ‘ and that the desktop TextArea can be accessed as described (this depends on the undocumented internal hierarchy, which may change between releases). For the moment these assumptions seem valid.

By: Mike

Mike — Tue, 26 Jan 2010 02:18:29 +0000

Very Interesting. Have you found any issues with operations that make assumptions about the prompt, such as tab completion, or copying/pasting to the Editor?