bugGNU Octave - Bugs: bug #54310, Synchronize file encoding used in...

 
 

bug #54310: Synchronize file encoding used in editor with the one used for executing m files

Submitter:  Markus Mützel <mmuetzel>
Submitted:  Sat 14 Jul 2018 10:28:24 AM UTC
   
 
Category:  GUI Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  ttl
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 30 Jul 2018 07:21:59 PM UTC, comment #5: 

Works for me on Linux and Windows in both directions.
I think the GUI translating to a "canonical" codepage name might be considered as a nice feature.

Closing as fixed.

Thanks.

Markus Mützel <mmuetzel>
Group administrator
Sun 29 Jul 2018 11:30:51 AM UTC, comment #4: 

changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/bd30c6f8cfb7
implements the other way, i.e. updating _mfile_encoding_ whenever the gui preference changes. Currently there is no modification since windows-1250 or ibm850 seens to be okay for _mfile_encoding_.

However, there is a minor issue: it is not possible to determine who has called _octave_link_gui-preference_. Assume, it was _mfile_encoding_ setting the encoding to "cp1250". Then the gui preference is updated to "WINDOWS-1250". Since this change might be initiated by some other internal function (not _mfile_encoding_) the gui "updates" _mfile_encoding_ resulting in "windows-1250" instead of "cp1250". Due to this change, there is another request for updating the gui preference, however, here the cycle stops since the gui preference would not change.

Torsten Lilge <ttl>
Group Member
Sat 28 Jul 2018 10:11:54 AM UTC, comment #3: 

Thanks Torsten!
Changing the setting with _mfile_encoding_ also successfully changes the editor setting in the preferences for me on Ubuntu Linux. I'll try with a Windows cross-build later.
Changing the encoding setting in the preferences dialog doesn't change the _mfile_encoding_ for me. But I guess that isn't implemented yet.

I didn't realize that iconv and Qt used different names to identify the encodings. That might complicate things as there is no way of querying a list of all valid encodings from iconv (as of now).
However, iconv seems to be more "forgiving" when it comes to using alternative character codec identifiers: _mfile_encoding_ ("cp1252") seems to work as does _mfile_encoding_ ("windows-1252"). At least on Ubuntu 18.04.
So we might be able to just set whatever Qt uses as an identifier for iconv as well.

Markus Mützel <mmuetzel>
Group administrator
Sat 28 Jul 2018 06:57:12 AM UTC, comment #2: 

I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/ba8227df92ae
which implements the synchronization from _mfile_encodings_ into the gui settings using the new _octave_link_gui_preference_ function. A problem was that the codec names do not completely match in the two environments.

I was not completely sure whether to call _octave_link_gui_preference_ in input_sys::mfile_encoding or directly in _mfilter_encoding_. I have chosen the first option.

Torsten Lilge <ttl>
Group Member
Sat 14 Jul 2018 05:35:46 PM UTC, comment #1: 

A bit of brainstorming here:

This is probably an example of what I've imagined as an OOP-like way for the GUI to override any function yet still call the (let's call it) "base script".  In pseudo-code, say there were some C function or a script such as


install_custom_override (__mfile_encoding__, __gui_mfile_encoding__);


for which we could do


octave_value __gui_mfile_encoding__(octave_value args)
{
  CALL_BASE_FUNCTION (args);

  if (success)
    write_the_gui_code_here();
}


It would be a really convenient means of integrating a GUI (any, not necessarily the Qt one) without extra code from the core's side.  All the responsibility for debugging would be on the GUI side.  This would help in the case of setting/clearing breakpoints, exit, etc.

So, at the start of the GUI code after launching the worker thread, it might be something like


install_custom_override (dbstop, gui_dbstop);
install_custom_override (dbstep, gui_dbstep);
install_custom_override (dbclear, gui_dbclear);
install_custom_override (exit, gui_exit);
install_custom_override (__mfile_encoding__, __gui_mfile_encoding__);


The key thing is to still be able to call that existing base routine, just like in OOP programming.  It's a bit of work on part of the parser and so on, but once it's generalized, no more work on the core's part.  There must already be function-pointer tables of some sort because Octave allows defining functions.

Dan Sebald <sebald>
Sat 14 Jul 2018 10:28:24 AM UTC, original submission:  

We currently have two independent settings for the character encoding used in the internal editor ("Text encoding used for loading and saving" in the Editor Preferences) and the character encoding that is used when executing an .m file (controlled by _mfile_encoding_).
It would be nice if these two settings could be unified or kept in sync. I.e. when changing the default character encoding for the Editor, the _mfile_encoding_ should be changed accordingly and vice versa.

Torsten agreed to have a look at this.

Markus Mützel <mmuetzel>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by mmuetzel (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-30 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-07-29 ttl StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code