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

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

[Octave-bug-tracker] [bug #39723] history commands lost when selecting b


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #39723] history commands lost when selecting block and right-clicking "Evaluate"
Date: Fri, 23 Aug 2013 20:01:16 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

Follow-up Comment #6, bug #39723 (project octave):

This does seem to behave better than the previous patch.  In the previous
patch I was able to get things into a state where the executed commands didn't
appear until every one of the evaluate commands was through.  Now, individual
commands appear as they are completed and then Octave moves onto the next
queued command.  I'm able to intermix other callback items like debug commands
and so on.

One behavior that would be worth changing (but as a separate patch) is the
fact that if commands are running and one selects some lines in the history
column (say I want to copy some lines from the history while evaluated
commands are running), when the Octave command in the terminal is complete,
the highlighted commands in the history are deactivated.  I don't know how
this works though--it might go into Octave core and eventually to a function
called "rl_redisplay" and then come back to the terminal emulation that grabs
focus when it redisplays.  I can't find "rl_redisplay" in the source tree, so
maybe that is a readline library kind of thing.  Probably is because the same
thing happens if I type a command in the command window when something is
selected.  Save this for another patch if it becomes too ancillary.

Why limit the queue to 512?  Seems arbitrary and the queue, as far as I know,
isn't like some buffer which takes up the maximum amount of space.  I would
think it is link-list-based.  If the user finds a need to put so many commands
in the queue and that bogs down the system, it is for his or her reasons.  The
worst that could happen is if a user accidentally types Cntrl-a which selects
all of history and then executes the commands.  How likely that is to happen,
I don't know.  The history is already limited (with the default being 1000),
so if the user expands history, maybe they want to be able to select big
blocks in history.  (Of course, I'd advise them to create a script file to
re-run commands.)

In summary, this is an improvement and works nicely.  I'd just prefer it not
be entwined with callbacks the way it is.  On the whole, I guess it is worth
applying the patch.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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